On Thu, Sep 1, 2022, at 3:46 PM, Russell King (Oracle) wrote:
On Thu, Sep 01, 2022 at 03:12:57PM +0200, Arnd Bergmann wrote:
Ah, I forgot that systemd actually needs it. So I guess there is currently no way to use systemd on 32-bit machines that are meant to survive 2038, regardless of whether systemd and glibc are built with a 64-bit time_t or not, right?
Is there perhaps a way to change the logic in a way that it does not depend on the current time but instead depends on a property of the RTC device itself, so we make systems break immediately instead of by surprise in 2038?
Are you seriously suggesting to cause regressions on systems where the RTC can send the kernel's timekeeping back to the early 1900s, rather than printing a big fat warning message in the kernel log?
I think the systems that can send the timekeeping back into the early 1900s (or at least after 1970) are fine, the problem is the systems that can randomly send the timekeeping into the post-2038 future.
What kind of warning would you suggest to print here? I don't see how warning about broken hardware at every boot would help, since there is no way for users to react to that warning. Similarly, warning about a time_t value past 2038 does not help because at that time one either has a bricked system (if using a systemd with 32-bit time_t) or it is actually 2038 and the system reverts back to 1970.
What might work is to have all drivers for broken RTC devices default to a 1902-2037 (or 1970-2037) date range to ensure that only those devices are broken in 2038, but still allow overriding the "start-year" property in DT for machines that don't use the broken systemd.
Arnd