This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: New kernel interface for sys_tz and timewarp?
- From: Lennart Poettering <mzxreary at 0pointer dot de>
- To: Alexandre Belloni <alexandre dot belloni at bootlin dot com>
- Cc: Arnd Bergmann <arnd at arndb dot de>, "Theodore Y. Ts'o" <tytso at mit dot edu>, Linus Torvalds <torvalds at linux-foundation dot org>, Linux Kernel Mailing List <linux-kernel at vger dot kernel dot org>, Thomas Gleixner <tglx at linutronix dot de>, John Stultz <john dot stultz at linaro dot org>, Stephen Boyd <sboyd at kernel dot org>, Florian Weimer <fweimer at redhat dot com>, "H. Peter Anvin" <hpa at zytor dot com>, Palmer Dabbelt <palmer at dabbelt dot com>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Karel Zak <kzak at redhat dot com>, OGAWA Hirofumi <hirofumi at mail dot parknet dot co dot jp>
- Date: Wed, 14 Aug 2019 14:15:07 +0200
- Subject: Re: New kernel interface for sys_tz and timewarp?
- References: <CAK8P3a0VxM1BkjY1D2FfHi6L-ho_NH3v3+gBu45EfpjLF5NU5w@mail.gmail.com> <CAHk-=wiO2CWONDBud4nxoPgUJN1JEewFWhHa5wAqY8G5rrTXRQ@mail.gmail.com> <20190814000622.GB20365@mit.edu> <CAK8P3a1CXRETxn6Gh_cOxM3rZ-wUwVDu-7=yEwjqOY=uEdC6OQ@mail.gmail.com> <20190814090936.GB10516@gardel-login> <20190814093208.GG3600@piout.net>
On Mi, 14.08.19 11:32, Alexandre Belloni (alexandre.belloni@bootlin.com) wrote:
> On 14/08/2019 11:09:36+0200, Lennart Poettering wrote:
> > On Mi, 14.08.19 10:31, Arnd Bergmann (arnd@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