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: Arnd Bergmann <arnd at arndb dot de>
- To: "Theodore Y. Ts'o" <tytso at mit dot edu>, Linus Torvalds <torvalds at linux-foundation dot org>, Arnd Bergmann <arnd at arndb dot de>, 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>, Alexandre Belloni <alexandre dot belloni at bootlin dot com>, 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>, Lennart Poettering <lennart at poettering dot net>, OGAWA Hirofumi <hirofumi at mail dot parknet dot co dot jp>
- Date: Wed, 14 Aug 2019 10:31:33 +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>
On Wed, Aug 14, 2019 at 2:06 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> On Tue, Aug 13, 2019 at 10:30:34AM -0700, Linus Torvalds wrote:
> >
> > I suspect the only actual _valid_ use in the kernel for a time zone
> > setting is likely for RTC clock setting, but even that isn't really
> > "global", as much as "per RTC".
>
> As I recall (and I may or may not have been original for the original
> sys_tz; it was many years ago, and my memories of 1992 are a bit
> fuzzy) the only reason why we added it was because x86 systems that
> were dual-booting with Windows had a RTC which ticked localtime, and
> originally, the system time was fetched from the RTC in early boot,
> and then when the timezone was set, the time would be warped so it
> would be correct.
I think this was the case from 1992 to commit 84e345e4e209 ("time,
Fix setting of hardware clock in NTP code") in 2013, when we started
taking the time warp into account during the periodic sync_cmos_clock()
call from kernel/time/ntp.c.
> Trying to use this for anything else is probably a bad idea, and in a
> world where we can have initrd's and reading the RTC gets done by
> userspace as opposed to kernel, it probably doesn't make any sence to
> keep it.
As Alexandre keeps pointing out, we really ought to do this from user
space, but in systemd today still relies on the kernel setting the
initial time using CONFIG_RTC_HCTOSYS, but this breaks e.g.
when the rtc driver itself is a loadable module.
>From what I understand it would be easy for systemd to sync the
rtc to system time at boot and let distros disable CONFIG_RTC_HCTOSYS,
but it still has to do the initial settimeofday(NULL, tz) call to
ensure the correct offset is used for sync_hw_clock() in case
CONFIG_GENERIC_CMOS_UPDATE or CONFIG_RTC_SYSTOHC
are set (which they tend to be at the moment).
In the long run, a distro can decide to avoid this all, once these
bits come together:
- 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
- systemd reads the RTC at boot and sets the system
time according to the configuration in /etc/localtime and /etc/adjtime
- systemd, ntp or something else in user space takes care of the periodic
rtc update, again taking configuration into account.
When someone mixes today's glibc/systemd/kernel with other
components past that migration, things can go wrong somewhat
annoying but non-fatal ways:
- Users that dual-boot with windows may have to force Windows
to set the RTC to UTC mode rather than setting Linux to
localtime.
- if neither the kernel not user space do the periodic RTC update,
it may be out of sync and cause a larger time jump after the
next boot time ntp synchronization
Creating a kernel interface for systemd to see or contol how the
11-minute update is done in the kernel would help part of that
transition.
Arnd