On Wed, 2022-11-30 at 12:02 +0100, Alexandre Belloni via
lists.openembedded.org wrote:

On 30/11/2022 09:07:50+0100, Alexander Kanavin wrote:

On Tue, 29 Nov 2022 at 16:45, Stephen Jolley <sjolley.yp.pm@...> 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.

What is the potential issue with builtools?

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.

To be clear, we don't run ptests on 32 bit targets, only on qemux86-64
and qemuarm64 where we have KVM available. We do run image, sdk and
eSDK tests on our supported qemu targets, 32 and 64 bit.

Cheers,

Richard

On Wed, 30 Nov 2022 at 12:40, Richard Purdie
<richard.purdie@...> wrote:

To be clear, we don't run ptests on 32 bit targets, only on qemux86-64
and qemuarm64 where we have KVM available. We do run image, sdk and
eSDK tests on our supported qemu targets, 32 and 64 bit.

I think kvm does allow 32 bit guest on a 64 bit host. But I can
imagine making full ptests work on 32 bit guests would be a struggle
for reasons unrelated to 2038, specifically lack of users outside of
embedded world.

Alex

On Wed, 30 Nov 2022 13:07:27 +0100
"Alexander Kanavin" <alex.kanavin@...> wrote:

On Wed, 30 Nov 2022 at 12:40, Richard Purdie
<richard.purdie@...> wrote:

To be clear, we don't run ptests on 32 bit targets, only on
qemux86-64 and qemuarm64 where we have KVM available. We do run
image, sdk and eSDK tests on our supported qemu targets, 32 and 64
bit.

I think kvm does allow 32 bit guest on a 64 bit host.

+1

IIRC the MACH=qemux86 was working correctly...

But I can
imagine making full ptests work on 32 bit guests

Maybe only subset of ptests - i.e. those related to Y2038 could be run?

would be a struggle
for reasons unrelated to 2038, specifically lack of users outside of
embedded world.

Alex

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@...

On Wed, 2022-11-30 at 13:07 +0100, Alexander Kanavin wrote:

On Wed, 30 Nov 2022 at 12:40, Richard Purdie
<richard.purdie@...> wrote:

To be clear, we don't run ptests on 32 bit targets, only on qemux86-64
and qemuarm64 where we have KVM available. We do run image, sdk and
eSDK tests on our supported qemu targets, 32 and 64 bit.

I think kvm does allow 32 bit guest on a 64 bit host.

For x86, yes. For arm, it varies and I know at least one of our arm
hosts doesn't support it, I don't know about the newer ones.

But I can imagine making full ptests work on 32 bit guests would be a struggle
for reasons unrelated to 2038, specifically lack of users outside of
embedded world.

In general I think it shouldn't be too bad but we really do need to
test it and see.

Cheers,

Richard