Re: Accelerating Y2038 glibc fixes

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4286 bytes --]



On 17/07/2019 13:18, Lukasz Majewski wrote:
> Hi Florian,
> 
>> * 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?
> 
> The __ASSUME_TIME64_SYSCALLS was discussed with Joseph and Stepan (both
> CC'ed) for a long time on the libc-alpha mailing list. The discussion
> can be found here [1] (last link is the newest one).
> 
> 
> 
> As fair as I understood from the previous discussion, adding
> __ASSUME_TIME64_SYSCALLS is a first step to add Y2038 support (or 64 bit
> time support to 32 bit archs in general).
> 
> The latest patch (v8) with semantics explanation of
> __ASSUME_TIME64_SYSCALLS: [2]
>  
> Note:
> 
> [1] Evolution of __ASSUME_TIME64_SYSCALLS up till v7:
> 
> https://patchwork.ozlabs.org/patch/1092579/
> https://patchwork.ozlabs.org/patch/1096343/
> https://patchwork.ozlabs.org/patch/1096349/
> https://patchwork.ozlabs.org/patch/1097132/
> https://patchwork.ozlabs.org/patch/1100097/
> https://patchwork.ozlabs.org/patch/1107125/
> https://patchwork.ozlabs.org/patch/1114061/
> https://patchwork.ozlabs.org/patch/1117100/
> 
> [2] - https://patchwork.ozlabs.org/patch/1117100/

More and more I see that a possible disruption in a release due to a 
possible ABI change should be a net gain over time by moving to a better
alternative.  The off64 migration required a lot of efforts and its 
issues still hit us in a way or another (BZ#23960), especially because 
off64 is *not* default for 32-bit builds neither on new 32-bits ports 
(on glibc side). Even now, from BZ#23960 comments, it seems that 
distributions still do not use LFS for some packages builds, it required 
Linux to force us to move forward.

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)? 

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.

And yes, it will mostly break stuff once people start to build distributions 
with these options. However, it will save us time to figure out all the bits
and joints required at cost of an initially high cost of adaptation plus
the all required code complexity and testing to support the multiple 
permutation possible.

I also wish we could also move forward with off_t and set LFS as default
as well.


  


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]