On Mi, 14.08.19 11:32, Alexandre Belloni (alexandre.bell...@bootlin.com) wrote:
> On 14/08/2019 11:09:36+0200, Lennart Poettering wrote: > > On Mi, 14.08.19 10:31, Arnd Bergmann (a...@arndb.de) wrote: > > > > > - glibc stops passing the caller timezone argument to the kernel > > > - the distro kernel disables CONFIG_RTC_HCTOSYS, > > > CONFIG_RTC_SYSTOHC and CONFIG_GENERIC_CMOS_UPDATE > > > > What's the benefit of letting userspace do this? It sounds a lot more > > fragile to leave this syncing to userspace if the kernel can do this > > trivially on its own. > > > > It does it trivially and badly: > > - hctosys will always think the RTC is in UTC so if the RTC is in > local time, you will anyway have up to 12 hours difference until > userspace fixes that. Sure, but 12h off is not that bad, much better than being 39years off. Moreover, it's off only for those who actually dual boot Windows and make use of the RTC-in-local-time functionality. For them having the time slightly off during early boot is not great but also not totally afwul, and the whole concept of RTC-in-local-time is not that great anyway. It's not a reason to penalize everybody else who has the RTC in UTC, as they should. > - the RTC to be used for hctosys and systohc is hardcoded in Kconfig > and distro usually let the default rtc0 but many platforms have a non > functional RTC that ends up being rtc0. I would prefer that to be a > userspace configuration change instead of a kernel configuration > change Well, but how do you think userspace would figure out which RTC to use in a way the kernel couldn't do equally well or better? On PCs at least it's very clear which RTC driver is the right one. And if non-PC hardware comes with borked RTC hw then it's probably a good idea not to compile support for such RTCs into the kernel in the first place... I know that there are some environments where RTC devices are compiled as modules. But that means they are loaded relatively late during the boot process, i.e. at a time where udevd is started and triggers all busses, but that's *very* late in most cases, and it woud suck having timestamps in early-boot logs that are 39y off until that point. I'd argue that in the vast majority of cases the person building the kernel for a device knows very well which RTC is connected to the device they are interested in, and should just build that driver in, and don't bother with userspace complexity, later userspace module loading or anything like that. Lennart -- Lennart Poettering, Berlin