From: Lukasz Majewski <lukma@denx.de>
To: "Alexander Kanavin" <alex.kanavin@gmail.com>
Cc: openembedded-architecture
<openembedded-architecture@lists.openembedded.org>,
Yocto-mailing-list <yocto@lists.yoctoproject.org>,
OE-core <openembedded-core@lists.openembedded.org>,
Stephen Jolley <sjolley.yp.pm@gmail.com>,
Richard Purdie <richard.purdie@linuxfoundation.org>
Subject: Re: [yocto] Y2038 proposal
Date: Wed, 30 Nov 2022 09:28:32 +0100 [thread overview]
Message-ID: <20221130092832.62067104@wsk> (raw)
In-Reply-To: <CANNYZj8Y37+s6Jzo1XvX0uCYNFc=NqOH8PWrFSL9_=TOS2ja7Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]
Hi Alexander,
> 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.
>
Please find a few comments:
1. There is already provided meta-y2038 [1] to test if 32 bit systems
correctly support Y2038 problem. It uses qemu machines from OE/Yocto
2. There are ptest available [2] to validate if the Y2038 problem works
correctly.
3. Support for running ptests mentioned in point 2. is already
available in the poky repository [3].
> 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.
>
Yes, y2038 is an important issue.
I would be more than happy if we could reuse the previous work [1].
I've used OE/Yocto to validate the code during developing support for
'-D_TIME_BITS=64 ' flag in glibc.
It looks like the meta-y2038 can be used out of the box (after checking
if it still works with newest poky) when added to the Yocto Project
build/test infrastructure.
> Alex
Links:
[1] - https://github.com/lmajewski/meta-y2038
[2] - https://github.com/lmajewski/meta-y2038/blob/master/README#L201
[3] -
https://git.yoctoproject.org/poky/commit/?id=0e0c481a25f10f8f7ff1d69bda7f015186da0202
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 --]
next prev parent reply other threads:[~2022-11-30 8:28 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 15:44 Yocto Project Status 29 November 2022 (WW48) sjolley.yp.pm
2022-11-30 8:07 ` Y2038 proposal Alexander Kanavin
2022-11-30 8:28 ` Lukasz Majewski [this message]
2022-11-30 9:07 ` [yocto] " Alexander Kanavin
2022-11-30 9:40 ` Lukasz Majewski
2022-11-30 9:48 ` Alexander Kanavin
2022-11-30 21:14 ` Alexander Kanavin
2022-12-01 8:28 ` Lukasz Majewski
2022-11-30 11:02 ` Alexandre Belloni
2022-11-30 11:40 ` [OE-core] " Richard Purdie
2022-11-30 12:07 ` Alexander Kanavin
2022-11-30 12:09 ` Lukasz Majewski
2022-11-30 12:11 ` Richard Purdie
2022-11-30 13:15 ` [Openembedded-architecture] " Richard Purdie
2022-11-30 13:36 ` [OE-core] " Lukasz Majewski
2022-11-30 14:20 ` Richard Purdie
2022-11-30 16:46 ` [yocto] " Ross Burton
2022-11-30 16:56 ` Alexandre Belloni
2022-11-30 16:59 ` Richard Purdie
2022-12-05 10:00 ` Ola x Nilsson
2022-12-05 11:04 ` Richard Purdie
2022-12-05 11:05 ` Ola x Nilsson
2022-12-01 10:27 ` Alexander Kanavin
2022-12-01 10:36 ` Richard Purdie
2022-11-30 16:38 ` Khem Raj
2022-12-02 8:54 ` [OE-core] " Matt Johnston
2022-12-05 23:24 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221130092832.62067104@wsk \
--to=lukma@denx.de \
--cc=alex.kanavin@gmail.com \
--cc=openembedded-architecture@lists.openembedded.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
--cc=sjolley.yp.pm@gmail.com \
--cc=yocto@lists.yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox