On Fri, Jun 28, 2024, at 00:43, Alexandre Belloni wrote:
> On 24/06/2024 11:41:41+0000, Leonard Anderweit wrote:
>> Hi,
>>
>> I found this patch [1] which is necessary for a project I'm currently
>> working on. I'm using phyboard-wega [2] with an am335 ARM SoC which I
>> want to make y2038 proof.
>> Is there any reason it was never accepted?
Sorry for not having replied earlier. I'm definitely interested
in helping to make this work better, having spent a lot of time
on the kernel side of the y2038 work.
Which combination of distro, libc and init system are you using
in your work?
Are you running with COMPAT_32BIT_TIME disabled? This is something
you probably want in order to better test for corner cases that
still use time32 kernel ABIs somewhere, but it still requires
adding a few more workarounds in libc and other userspace
sources.
> The systemd maintainer think the kernel is well placed to take a
> decision it can't actually take so they won't fix a bug where systemd is
> crashing when userspace is 32bit.
>
> The whole situation is frustrating and honestly, nobody should use the
> hctosys insanity anyway. Obviously systemd mandates its usage and this
> is yet another topic on which they think the kernel is better placed to
> take decisions that are actually userspace policy.
>
> I've been arguing for a while and gave up.
I thought that systemd had at least fix the bug where it would
crash when a random 64-bit time was set, so we could try again
with this patch and see what breaks?
An important difference now is that Debian is finally changing
to a time64 userspace, which both avoids the problem that
the broken rtc_hctosys() time truncation was trying to work
around (all times returned here are now valid) and it means
that there is a much higher incentive to actually make
a systemd based userland work past 2038.
Arnd
