On Tue, 29 Nov 2022 at 16:45, Stephen Jolley <sjolley.yp...@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? 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. Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#173995): https://lists.openembedded.org/g/openembedded-core/message/173995 Mute This Topic: https://lists.openembedded.org/mt/95354043/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
