Re: Accelerating Y2038 glibc fixes

[Lukasz Majewski <lukma at denx dot de>]

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/

> 
> Thanks,
> Florian




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

Attachment: pgpp8QuQaMvXy.pgp
Description: OpenPGP digital signature