On Tue, 18 Feb 2025 at 16:40, Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> wrote: > > On 18/02/2025 15:51:24+0100, Arnd Bergmann wrote: > > On Tue, Feb 18, 2025, at 14:30, Alexandre Belloni wrote: > > > On 18/02/2025 13:45:56+0100, Einar Jón wrote: > > >> Hello again > > >> > > >> On second thought, removing is too general. > > >> But it's still very much broken. Is there any reason why this was not > > >> merged? > > >> https://lore.kernel.org/all/c5e8ab50-aacb-4651-8893-a6dd9edcd155@xxxxxxxxxxxxxxxx/T/ > > >> > > >> Any thoughts on how this should be handled? > > > > > > The first step is to convince Lennart that mandating RTC_HCTOSYS xwas a > > > bad idea, the second step is to let userspace set the time instead. The > > > kernel can't take the proper decision because it simply doesn't know > > > whether userspace is TIME64 ready or not. > > > > It's been seven years since the you added the workaround, and > > there are a few things that have changed in the meantime: > > > > - most distros that use systemd have stopped supporting > > 32-bit targets > > - most distros that still support 32-bit have moved to a > > 64-bit time_t > > - 2038 is only 13 years away instead of 20, adding to the > > urgency of having future-proof default behavior. > > > > 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. This triggered me on a yocto build (armhf) that is indeed using 64-bit time_t and systemd. I just assumed everyone is on 64-bit time_t already, since glibc made the change like 3 years ago. My bad. > 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. I have over a decade until this becomes urgent. I'll be OK with it being unchanged for a little longer. > Or am I missing anything? Without a doubt. So let's not rock the boat and keep it as is. Although printing a warning before err = -ERANGE; would be nice. > > -- > Alexandre Belloni, co-owner and COO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -- Regards Einar Jón
