Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal
On Mon, Dec 05 2022, Richard Purdie wrote: > On Mon, 2022-12-05 at 11:00 +0100, Ola x Nilsson wrote: >> On Wed, Nov 30 2022, Richard Purdie wrote: >> >> > On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote: >> > > On 30/11/2022 16:46:17+, Ross Burton wrote: >> > > > On 30 Nov 2022, at 14:20, Richard Purdie via >> > > > lists.yoctoproject.org >> > > > wrote: >> > > > > > > * 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? >> > > > > >> > > > > I'm meaning disabling the 32 bit glibc time functions. >> > > > >> > > > Some time ago I filed >> > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian >> > > > has a nice sanity check where it warns if non-LFS glibc functions >> > > > are used. I imagine the same logic could be used to check for 32- >> > > > bit time_t use. >> > >> > That sounds interesting and something we should probably look into for >> > both issues... >> >> I have a working sanity checker that checks for any glibc functions >> affected by -D_FILE_OFFSET_BITS=64 or -D_TIME_BITS=64. >> The INSANE_SKIP functionality needs some more polish but I'd be happy to >> contribute it. >> >> Some libraries use both 32 and 64 bit APIs to glibc and needs exceptions >> in the checker. >> >> I have not run any world builds with this checker, I've focused on the >> recipes we actually use so far so we could get to a testable system. My >> biggest worry at the moment is rust, I know to little to know if it is >> an actual problem and how to fix it. >> >> I would like to be part of any "y2038 team" for Yocto. > > That does sound useful, perhaps sharing it as an RFC patch might be a > good place to start? We might be able to run one of the autobuilder > world targets against it, see how it looks for our core recipes? That works for me. I've started preparing a patch for oe-core. -- Ola x Nilsson -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1688): https://lists.openembedded.org/g/openembedded-architecture/message/1688 Mute This Topic: https://lists.openembedded.org/mt/95361985/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal
On Mon, 2022-12-05 at 11:00 +0100, Ola x Nilsson wrote: > On Wed, Nov 30 2022, Richard Purdie wrote: > > > On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote: > > > On 30/11/2022 16:46:17+, Ross Burton wrote: > > > > On 30 Nov 2022, at 14:20, Richard Purdie via > > > > lists.yoctoproject.org > > > > wrote: > > > > > > > * 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? > > > > > > > > > > I'm meaning disabling the 32 bit glibc time functions. > > > > > > > > Some time ago I filed > > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian > > > > has a nice sanity check where it warns if non-LFS glibc functions > > > > are used. I imagine the same logic could be used to check for 32- > > > > bit time_t use. > > > > That sounds interesting and something we should probably look into for > > both issues... > > I have a working sanity checker that checks for any glibc functions > affected by -D_FILE_OFFSET_BITS=64 or -D_TIME_BITS=64. > The INSANE_SKIP functionality needs some more polish but I'd be happy to > contribute it. > > Some libraries use both 32 and 64 bit APIs to glibc and needs exceptions > in the checker. > > I have not run any world builds with this checker, I've focused on the > recipes we actually use so far so we could get to a testable system. My > biggest worry at the moment is rust, I know to little to know if it is > an actual problem and how to fix it. > > I would like to be part of any "y2038 team" for Yocto. That does sound useful, perhaps sharing it as an RFC patch might be a good place to start? We might be able to run one of the autobuilder world targets against it, see how it looks for our core recipes? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1687): https://lists.openembedded.org/g/openembedded-architecture/message/1687 Mute This Topic: https://lists.openembedded.org/mt/95361985/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal
On Wed, Nov 30 2022, Richard Purdie wrote: > On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote: >> On 30/11/2022 16:46:17+, Ross Burton wrote: >> > On 30 Nov 2022, at 14:20, Richard Purdie via >> > lists.yoctoproject.org >> > wrote: >> > > > > * 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? >> > > >> > > I'm meaning disabling the 32 bit glibc time functions. >> > >> > Some time ago I filed >> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian >> > has a nice sanity check where it warns if non-LFS glibc functions >> > are used. I imagine the same logic could be used to check for 32- >> > bit time_t use. > > That sounds interesting and something we should probably look into for > both issues... I have a working sanity checker that checks for any glibc functions affected by -D_FILE_OFFSET_BITS=64 or -D_TIME_BITS=64. The INSANE_SKIP functionality needs some more polish but I'd be happy to contribute it. Some libraries use both 32 and 64 bit APIs to glibc and needs exceptions in the checker. I have not run any world builds with this checker, I've focused on the recipes we actually use so far so we could get to a testable system. My biggest worry at the moment is rust, I know to little to know if it is an actual problem and how to fix it. I would like to be part of any "y2038 team" for Yocto. -- Ola x Nilsson -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1686): https://lists.openembedded.org/g/openembedded-architecture/message/1686 Mute This Topic: https://lists.openembedded.org/mt/95361985/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] Y2038 proposal
On Thu, 2022-12-01 at 11:27 +0100, Alexander Kanavin wrote:
> On Wed, 30 Nov 2022 at 14:15, Richard Purdie
> wrote:
> > * 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?
>
> I just ran qemux86 full ptest locally. It took 4h:10m (same as
> qemuarm64 ptest on an arm worker). The fails were:
>
> {'python3': ['test_deterministic_sets'],
> 'valgrind': ['gdbserver_tests/hgtls',
> 'gdbserver_tests/mcblocklistsearch',
> 'gdbserver_tests/mcbreak',
> 'gdbserver_tests/mcclean_after_fork',
> 'gdbserver_tests/mchelp',
> 'gdbserver_tests/mcinfcallRU',
> 'gdbserver_tests/mcinfcallWSRU',
> 'gdbserver_tests/mcinvokeRU',
> 'gdbserver_tests/mcinvokeWS',
> 'gdbserver_tests/mcleak',
> 'gdbserver_tests/mcmain_pic',
> 'gdbserver_tests/mcsignopass',
> 'gdbserver_tests/mcsigpass',
> 'gdbserver_tests/mcvabits',
> 'gdbserver_tests/mcwatchpoints',
> 'gdbserver_tests/mssnapshot',
> 'gdbserver_tests/nlcontrolc',
> 'gdbserver_tests/nlgone_abrt',
> 'gdbserver_tests/nlgone_exit',
> 'gdbserver_tests/nlgone_return',
> 'gdbserver_tests/nlpasssigalrm',
> 'gdbserver_tests/nlsigvgdb',
> 'gdbserver_tests/nlvgdbsigqueue',
> 'memcheck/tests/linux/memfd_create',
> 'memcheck/tests/linux/timerfd-syscall',
> 'memcheck/tests/origin5-bz2',
> 'massif/tests/mmapunmap']}
>
> So I think we could as well fix these, and add full qemux86 ptest to
> a-full? It is not heavy on the builder machine (mostly just runs a
> single qemu thread), it's just long.
I think we should fix those and we should add the target to the
autobuilder but I'm reluctant to add a long test to a-full. The fact it
is relatively clean suggests it doesn't regress that often. We could do
something like a once a month trigger for it?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1683):
https://lists.openembedded.org/g/openembedded-architecture/message/1683
Mute This Topic: https://lists.openembedded.org/mt/95354042/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] Y2038 proposal
On Wed, 30 Nov 2022 at 14:15, Richard Purdie
wrote:
> * 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?
I just ran qemux86 full ptest locally. It took 4h:10m (same as
qemuarm64 ptest on an arm worker). The fails were:
{'python3': ['test_deterministic_sets'],
'valgrind': ['gdbserver_tests/hgtls',
'gdbserver_tests/mcblocklistsearch',
'gdbserver_tests/mcbreak',
'gdbserver_tests/mcclean_after_fork',
'gdbserver_tests/mchelp',
'gdbserver_tests/mcinfcallRU',
'gdbserver_tests/mcinfcallWSRU',
'gdbserver_tests/mcinvokeRU',
'gdbserver_tests/mcinvokeWS',
'gdbserver_tests/mcleak',
'gdbserver_tests/mcmain_pic',
'gdbserver_tests/mcsignopass',
'gdbserver_tests/mcsigpass',
'gdbserver_tests/mcvabits',
'gdbserver_tests/mcwatchpoints',
'gdbserver_tests/mssnapshot',
'gdbserver_tests/nlcontrolc',
'gdbserver_tests/nlgone_abrt',
'gdbserver_tests/nlgone_exit',
'gdbserver_tests/nlgone_return',
'gdbserver_tests/nlpasssigalrm',
'gdbserver_tests/nlsigvgdb',
'gdbserver_tests/nlvgdbsigqueue',
'memcheck/tests/linux/memfd_create',
'memcheck/tests/linux/timerfd-syscall',
'memcheck/tests/origin5-bz2',
'massif/tests/mmapunmap']}
So I think we could as well fix these, and add full qemux86 ptest to
a-full? It is not heavy on the builder machine (mostly just runs a
single qemu thread), it's just long.
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1682):
https://lists.openembedded.org/g/openembedded-architecture/message/1682
Mute This Topic: https://lists.openembedded.org/mt/95354042/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal
On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote: > On 30/11/2022 16:46:17+, Ross Burton wrote: > > On 30 Nov 2022, at 14:20, Richard Purdie via lists.yoctoproject.org > > wrote: > > > > > * 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? > > > > > > I'm meaning disabling the 32 bit glibc time functions. > > > > Some time ago I filed > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian > > has a nice sanity check where it warns if non-LFS glibc functions > > are used. I imagine the same logic could be used to check for 32- > > bit time_t use. That sounds interesting and something we should probably look into for both issues... > > > > We can simply disable COMPAT_32BIT_TIME in the kernel config. That would cause runtime issues but not build time linking ones? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1679): https://lists.openembedded.org/g/openembedded-architecture/message/1679 Mute This Topic: https://lists.openembedded.org/mt/95361985/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal
On 30/11/2022 16:46:17+, Ross Burton wrote: > On 30 Nov 2022, at 14:20, Richard Purdie via lists.yoctoproject.org > wrote: > >>> * 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? > > > > I'm meaning disabling the 32 bit glibc time functions. > > Some time ago I filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 > as Debian has a nice sanity check where it warns if non-LFS glibc functions > are used. I imagine the same logic could be used to check for 32-bit time_t > use. > We can simply disable COMPAT_32BIT_TIME in the kernel config. > Ross > > > -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1678): https://lists.openembedded.org/g/openembedded-architecture/message/1678 Mute This Topic: https://lists.openembedded.org/mt/95361985/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal
On 30 Nov 2022, at 14:20, Richard Purdie via lists.yoctoproject.org wrote: >>> * 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? > > I'm meaning disabling the 32 bit glibc time functions. Some time ago I filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian has a nice sanity check where it warns if non-LFS glibc functions are used. I imagine the same logic could be used to check for 32-bit time_t use. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1677): https://lists.openembedded.org/g/openembedded-architecture/message/1677 Mute This Topic: https://lists.openembedded.org/mt/95361985/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] Y2038 proposal
On Wed, Nov 30, 2022 at 12:08 AM Alexander Kanavin wrote: > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley 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. I have something like this on yoe/mut branch on contrib repo ( due to musl removing the LFS hacks). However there are packages which need to be fixed at build time. > b. qemu is always started with "-rtc base=2040-01-01", simulating > Y2038 actually occurring. this is a good time machine :) > 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? > Not much issues except that package fixes may need to be carried locally for a while. > 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 devetc home liblost+found media mntproc > run sbin sys tmp usrvar > root@qemux86:~# date -s "2040-01-01" > Sun Jan 1 00:00:00 UTC 2040 > root@qemux86:~# ls / > bin boot devetc home liblost+found media mntproc > run sbin sys tmp usrvar > 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 (#1676): https://lists.openembedded.org/g/openembedded-architecture/message/1676 Mute This Topic: https://lists.openembedded.org/mt/95354042/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [Openembedded-architecture] Y2038 proposal
On Wed, 2022-11-30 at 14:36 +0100, Lukasz Majewski wrote: > > On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote: > > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > > > 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 Perhaps, yes. > > * 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? I'm meaning disabling the 32 bit glibc time functions. > > 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. Right, but the 32 bit time functions/symbols are still available for older binaries. My point is that anything using those older functions is likely in need of attention so for Yocto Project/OE usage, identifying those would be helpful. If we were to disable them, that would make such usage very obvious. > > > 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. Not necessarily. If it were a binary library, compiled with 32 bit time_t, new binaries using it would use a different sized field. > The only problem happens when new binaries with 64 bit time support are > run on glibc or kernel not supporting 64 bit time. That is definitely not the only problem. Some of the problems are unlikely but we do need to consider them. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1675): https://lists.openembedded.org/g/openembedded-architecture/message/1675 Mute This Topic: https://lists.openembedded.org/mt/95357623/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [Openembedded-architecture] Y2038 proposal
Hi Richard, > On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote: > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > > 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: lu...@denx.de pgpuFLaJYsUzv.pgp Description: OpenPGP digital signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1674): https://lists.openembedded.org/g/openembedded-architecture/message/1674 Mute This Topic: https://lists.openembedded.org/mt/95357623/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] Y2038 proposal
On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote: > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley 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? * Could we optionally disable some of the glibc 32 bit function calls to ensure they're not being used? We don't really want to diverge from upstream glibc much though. * We need to work out how to communicate this change happened and have people "buy in" to it. The reason for that is that if someone has existing binaries, there could be problems using them after the change. We therefore need to be sure they are aware of it. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1673): https://lists.openembedded.org/g/openembedded-architecture/message/1673 Mute This Topic: https://lists.openembedded.org/mt/95354042/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[Openembedded-architecture] Y2038 proposal
On Tue, 29 Nov 2022 at 16:45, Stephen Jolley 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 devetc home liblost+found media mntproc run sbin sys tmp usrvar root@qemux86:~# date -s "2040-01-01" Sun Jan 1 00:00:00 UTC 2040 root@qemux86:~# ls / bin boot devetc home liblost+found media mntproc run sbin sys tmp usrvar 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 (#1663): https://lists.openembedded.org/g/openembedded-architecture/message/1663 Mute This Topic: https://lists.openembedded.org/mt/95354042/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
