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. 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? -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
