This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Fwd: Fifth draft of the Y2038 design document
- From: Zack Weinberg <zackw at panix dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 1 Mar 2017 20:38:56 -0500
- Subject: Fwd: 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> <alpine.DEB.2.20.1703011852200.20874@digraph.polyomino.org.uk> <CAKCAbMj6nZBwVZ2CWVutACLnJLM=6Ev3BXHTJCgMvSPQ7fiTig@mail.gmail.com>
[accidental off-list reply, sorry]
On Wed, Mar 1, 2017 at 1:55 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 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).
I'm not convinced this is even _possible_, and I don't see why it's
necessary to support old kernels _when 64-bit time_t is activated_.
Yes, fix all the code in glibc, but why can't --enable-64-bit-time-t
mean that the libc.so you get requires a newer kernel?
zw