Re: Accelerating Y2038 glibc fixes

[Rich Felker <dalias@libc.org>]

On Thu, Jul 18, 2019 at 05:31:51PM -0300, Adhemerval Zanella wrote:
> 
> 
> On 18/07/2019 16:13, Florian Weimer wrote:
> > * Adhemerval Zanella:
> > 
> >> So what about to not add a user-selected way to set the time_t size
> >> (as off_t) and just enable time64_t support and sets is as default for 
> >> build with a minimum kernel of v5.1 (if I recall correctly as being the 
> >> one that added time64 support)?
> > 
> > Does this mean that some developers see a glibc 2.31 with a 32-bit
> > time_t on i386, and others see a 64-bit time_t?
> > 
> >> It will move all time32 support as compat symbols for the required ABI, 
> >> without an option to select it through a build flag. Newer ports will
> >> just have the expected symbol names, no tinkering needed.
> > 
> > But if we build glibc with pre-5.1 kernel headers, you will get the
> > legacy interface?
> 
> My idea is to setup based on --enable-kernel and add a new EI_ABIVERSION
> when time64 is used.  So, depending on how glibc is built, developers
> will indeed see a different time_t.
> 
> Legacy builds won't build any time64 support, even with newer kernels.
> Build set with --enable-kernel will automatically set time_t as time64
> and redirect the required interfaces to the new symbols ones (similar
> to LFS, but transparently as _FILE_OFFSET_BITS=64 as being set as default).
> 
> Newer 32-bit ports won't require anything like this as expected.
> 
> I still think that in long term this initial bump transition is better
> than to the complexity from mixed support.

I see no reason for it to depend on the minimum kernel version glibc
is built for. You should be able to build glibc that runs on the
oldest still-supported kernels and that uses 64-bit time_t in the
application-facing ABI.

If built with --enable-kernel new enough, the fallback code to use old
syscalls when the time64 ones fail with ENOSYS can be omitted. If not,
the time64 syscalls are tried first, and if they fail, the old
syscalls are used and the results converted.

This is what musl has always planned to do regardless of whether we go
with a hard ABI break or symbol redirection. "Only works on
bleeding-edge kernels" is a sure way to make sure nobody uses the new
thing, resulting in continued production of legacy binaries that are
ticking timebombs far into the future, and all the exploding popcorn
when 2038 approaches...

Rich