Openembedded Core Discussions
 help / color / mirror / Atom feed
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 --]

  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