All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Lennart Poettering <mzxreary@0pointer.de>
Cc: Arnd Bergmann <arnd@arndb.de>, "Theodore Y. Ts'o" <tytso@mit.edu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	John Stultz <john.stultz@linaro.org>,
	Stephen Boyd <sboyd@kernel.org>,
	Florian Weimer <fweimer@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	GNU C Library <libc-alpha@sourceware.org>,
	Karel Zak <kzak@redhat.com>,
	OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Subject: Re: New kernel interface for sys_tz and timewarp?
Date: Wed, 14 Aug 2019 11:32:08 +0200	[thread overview]
Message-ID: <20190814093208.GG3600@piout.net> (raw)
In-Reply-To: <20190814090936.GB10516@gardel-login>

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.

 - the way systohc and hctosys are working will lead up to a 2 second
   drift until ntp runs which is an issue for NTP stratum servers. My
tests show that there is a way for userspace to reduce that to tens of
nanoseconds but this means having a one or two seconds delay when setting
and reading the time. I want that to be opt-in.

 - 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

> IIRC there are uses in kernel that use CLOCK_REALTIME already before
> userspace starts. e.g. iirc networking generally prefers
> CLOCK_REALTIME timestamps over CLOCK_MONOTONIC timestamps
> (i.e. SO_TIMESTAMP and friends are still CLOCK_REALTIME only so far,
> unless I am missing something). If the kernel comes up with a
> CLOCK_REALTIME that starts at 0 this is pretty annoying I
> figure... Hence, so far I suggested to distros to continue turning on
> the options above, and let the kernel do this on its own without
> involving userspace in that.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2019-08-14  9:32 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-13  9:05 New kernel interface for sys_tz and timewarp? Arnd Bergmann
2019-08-13 17:10 ` John Stultz
2019-08-13 21:45   ` Alexandre Belloni
2019-08-13 17:30 ` Linus Torvalds
2019-08-13 17:49   ` Paul Eggert
2019-08-13 19:31     ` Florian Weimer
2019-08-13 20:04       ` Arnd Bergmann
2019-08-13 21:56   ` Alexandre Belloni
2019-08-14  0:06   ` Theodore Y. Ts'o
2019-08-14  8:31     ` Arnd Bergmann
2019-08-14  9:09       ` Lennart Poettering
2019-08-14  9:32         ` Alexandre Belloni [this message]
2019-08-14 12:15           ` Lennart Poettering
2019-08-19 11:09           ` Karel Zak
2019-08-19 13:43             ` Thomas Gleixner
2019-08-19 13:49               ` Thomas Gleixner
2019-08-20 18:45                 ` Alexandre Belloni
2019-08-20 18:47               ` Alexandre Belloni
2019-08-20 18:58             ` Alexandre Belloni
2019-08-27 16:27               ` Arnd Bergmann
2019-08-27 16:31                 ` Alexandre Belloni
2019-08-14 16:26     ` David Laight
2019-08-14 16:47       ` hpa
2019-08-15 13:22         ` Arnd Bergmann
2019-08-15 15:05           ` Theodore Y. Ts'o
2019-08-15 15:24             ` hpa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190814093208.GG3600@piout.net \
    --to=alexandre.belloni@bootlin.com \
    --cc=alistair.francis@wdc.com \
    --cc=arnd@arndb.de \
    --cc=fweimer@redhat.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=hpa@zytor.com \
    --cc=john.stultz@linaro.org \
    --cc=kzak@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mzxreary@0pointer.de \
    --cc=palmer@dabbelt.com \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.