Re: [yocto] Y2038 proposal

[Alexandre Belloni <alexandre.belloni@bootlin.com>]

On 30/11/2022 09:07:50+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.
> 

I ran a-full with "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" last week, it
didn't go too well gcc-sanitizer and pulseaudio being the main offenders
but buildtools needs to be investigated.


> 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?
> 
> It's not hard to see that Y2038 problem is real and serious, e.g. on
> qemux86 core-image-full-cmdline built from master:
> 
> root@qemux86:~# ls /
> bin  boot  dev    etc  home  lib    lost+found  media  mnt    proc
> run  sbin  sys  tmp  usr    var
> root@qemux86:~# date -s "2040-01-01"
> Sun Jan  1 00:00:00 UTC 2040
> root@qemux86:~# ls /
> bin  boot  dev    etc  home  lib    lost+found  media  mnt    proc
> run  sbin  sys  tmp  usr    var
> root@qemux86:~# ls /
> -sh: ls: command not found
> 
> On qemux86_64 the same sequence works as expected, of course.
> 

The main issue with the plan is that we are not running tests on 32
qemu anymore.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com