Re: [OE-core] [Openembedded-architecture] Y2038 proposal

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 2743 bytes --]

Hi Richard,

> On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote:
> > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley
> > <sjolley.yp.pm@gmail.com> wrote:  
> > > We’d welcome a proposal/series on how to move forward with the
> > > Y2038 work for 32 bit platforms.  
> > 
> > I have the following proposal:
> > 
> > 1. A branch is made where:
> > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally.
> > b. qemu is always started with "-rtc base=2040-01-01", simulating
> > Y2038 actually occurring.
> > c. an additional runtime test verifies that both RTC clock and
> > system clock report 2040.
> > 
> > 2. This branch is run through a-full on the autobuilder. Any
> > uncovered issues are filed as bugs.
> > 
> > 3. Once *all* of the bugs are addressed, repeat point 2.
> > 
> > 4. Once there are no more open bugs, 1a is merged into master.
> > 
> > Any fatal flaws in the plan?  
> 
> Others have made some good comments. My thoughts:
> 
> * We need to add some runtime tests to oeqa for this (in addition to
> the ptests)
> 
> * We need to have a 32 bit ptest run on the autobuilder (qemux86
> should work, not sure we can make qemuarm fast). Whether this is
> manually triggered, not sure. We could have a smaller set of ptests
> to run for it?

Y2038 ptests maybe?

Here is the list of integrated tests to ptests:
https://github.com/lmajewski/y2038-tests

> 
> * Could we optionally disable some of the glibc 32 bit function calls
> to ensure they're not being used? 

Could you be more specific here? Would you like to disable some
syscalls?

> We don't really want to diverge from
> upstream glibc much though.

Could you be more specific here? The glibc now supports the whole set
of syscalls as of 2.34 version?

To enable them one needs to pass -D_TIME_BITS=64 flag when compiling
programs.

This is now the official glibc ABI.

> 
> * We need to work out how to communicate this change happened and have
> people "buy in" to it.

Ok.

> The reason for that is that if someone has
> existing binaries, there could be problems using them after the
> change.

The binary shall work without issues on glibc 2.34+ and 5.10+ kernel
without issues.

The only problem happens when new binaries with 64 bit time support are
run on glibc or kernel not supporting 64 bit time. 

> We therefore need to be sure they are aware of it.
> 
> Cheers,
> 
> Richard
> 
> 
> 
> 




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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]