Re: Accelerating Y2038 glibc fixes

[Florian Weimer <fweimer at redhat dot com>]

* Wolfgang Denk:

> Dear Florian,
>
> In message <875zo0911b.fsf@oldenburg2.str.redhat.com> you wrote:
>> * Arnd Bergmann:
>>
>> > b) Those that already need support for 64-bit time_t because
>> >     they are deploying new 32-bit binaries that are expected to run
>> >     beyond 2038, while not caring at all about compatibility
>> >     with existing binaries that are already known to be broken
>> >     for this purpose.
>>
>> There is also c), new 32-bit architectures which need 64-bit time_t
>> support today due to kernel limitations.  Whether those binaries need to
>> run for two years or twenty does not matter to them.
>>
>> I have reviewed patches for the c) case, but that doesn't seem to be
>> work that interests Wolfgang.
>
> Correct - our situation is Arnd's case b).
>
> But my understanding is that for c) glibc has to modify the generic
> syscalls wrapper (like clock_gettime/nanosleep/settime, etc.), and
> for b) we also need to do that first.  But currently we are stuck at
> the point where the __ASSUME_TIME64_SYSCALLS flag is not accepted /
> pulled.
>
> So b) and c) align in development...

Can you do without __ASSUME_TIME64_SYSCALLS?  Most other __ASSUME_*
macros are an optimization, and if your interest is b),
__ASSUME_TIME64_SYSCALLS will not be the default for glibc distribution
builds anyway because defining it would negatively impact host kernel
compatibility.  It's not just about containers in the fashionable sense,
but simple build chroots are problematic as well in this context.

Or have you received different guidance that __ASSUME_TIME64_SYSCALLS
markup is absolutely required for the initial contribution?

Thanks,
Florian