This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fifth draft of the Y2038 design document
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 1 Mar 2017 18:55:59 +0000
- Subject: Re: Fifth draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20170222090511.48be22ed.albert.aribaud@3adev.fr> <alpine.DEB.2.20.1702221647560.8704@digraph.polyomino.org.uk> <20170222194855.7581deca.albert.aribaud@3adev.fr> <alpine.DEB.2.20.1702222055440.24643@digraph.polyomino.org.uk> <20170223131634.06fa476c.albert.aribaud@3adev.fr> <alpine.DEB.2.20.1702231418320.15395@digraph.polyomino.org.uk> <20170223165052.1b494e3a.albert.aribaud@3adev.fr> <20170301081119.51cf96bb.albert.aribaud@3adev.fr> <CAKCAbMiuB7Au_x=AG-RSvLMaz7XEmQbRcevLbZZn13HxaJ9KUQ@mail.gmail.com>
On Wed, 1 Mar 2017, Zack Weinberg wrote:
> On Wed, Mar 1, 2017 at 2:11 AM, Albert ARIBAUD <albert.aribaud@3adev.fr> wrote:
> > GLIBC needs to provide 64-bit-time clock_gettime to 32-bit code in
> > various run-time cases:
> >
> > - above an 'old', only 32-bit-time, kernel;
> > - above a 'new', mixed 64- and 32-bit-time, kernel;
> > - above a 'newer', only 64-bit time, kernel.
>
> Is it really necessary to support 'old' kernels? That seems like it
> would add a great deal of complexity with no actual benefit.
It will be several years before glibc can require kernels newer than
currently exist (only when all current kernels are no longer maintained as
kernel.org releases, and maybe not even then if more issues like the one
with 2.6.32 containers arise). We want 64-bit time support in glibc
before all old kernels cease to be supported, and we want glibc-internal
uses of time-related interfaces to move over to using the 64-bit time
interfaces (without depending on new kernel support).
Obviously 64-bit glibc interfaces won't work with 32-bit kernel interfaces
after 2038, but the obsoletion of kernels lacking the new interfaces
should come long before that. And we may be able to depend on new kernel
headers to simplify things, just not on a new kernel at runtime.
--
Joseph S. Myers
joseph@codesourcery.com