On Tue, Feb 18, 2025, at 16:40, Alexandre Belloni wrote:
> On 18/02/2025 15:51:24+0100, Arnd Bergmann wrote:
>> On Tue, Feb 18, 2025, at 14:30, Alexandre Belloni wrote:
>>
>> I don't know how many 32-bit machines are affected by the bug
>> where they return a random time, or if they are more or less
>> common than in the past.
>
> This is going to break some of the Marvell board that RMK uses because I
> guess he is not updating his userspace.
>
> Also, I'd note that OpenEmbedded switched to 64-bit time_t by default
> just last year.
>
> I'm not against removing the workaround but keeping it doesn't actually
> break anyone, it is still possible to set the time properly from
> userspace as it should be done anyway so I'm not sure about the urgency.
> The impact is mostly about messages timestamp in the boot log, before
> being able to run hwclock or any similar tool.
>
> Or am I missing anything?
The main problem with the current approach is that it suddenly
breaks systems in the future (at the time_t overflow), which is
the opposite of how the rest of the time_t conversion worked.
We now have distros with systemd that advertize support [1],
and we know this breaks every single machine they run on that
uses an RTC to set the time.
Arnd
[1] https://ubuntu.com/blog/lts-cra-arm
