Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAK8P3a0VxM1BkjY1D2FfHi6L-ho_NH3v3+gBu45EfpjLF5NU5w@mail.gmail.com>
In-Reply-To: <CAK8P3a0VxM1BkjY1D2FfHi6L-ho_NH3v3+gBu45EfpjLF5NU5w@mail.gmail.com>
From:   John Stultz <john.stultz@linaro.org>
Date:   Tue, 13 Aug 2019 10:10:53 -0700
Message-ID: <CALAqxLUde4OTEm3Kik0Fvydhp+i-Xo-axS2wRKEBJyT9hY=wCg@mail.gmail.com>
Subject: Re: New kernel interface for sys_tz and timewarp?
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Florian Weimer <fweimer@redhat.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        "Theodore Ts'o" <tytso@mit.edu>, "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>,
        Lennart Poettering <lennart@poettering.net>,
        OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Aug 13, 2019 at 2:06 AM Arnd Bergmann <arnd@arndb.de> wrote:
> Now, to the actual questions:
>
> * Should we allow setting the sys_tz on new architectures that use only
>   time64 interfaces at all, or should we try to get away from that anyway?

So I'd probably cut this question a bit differently:

1) Do we want to deprecate sys_tz tracking in the kernel? If new
architectures don't have ways to set it, for consistency we should
probably deprecate in-kernel tracking of that value (start returning
an error when folks try to set it and always return 0 when its
accessed).

2) If we deprecate the sys_tz tracking in the kernel, how do we
address the in-kernel systohc syncing with local-time (non-UTC) RTCs
on x86 systems (I'm not aware of other arches that utilize non-UTC
RTCs)


> * Should the NTP timewarp setting ("int persistent_clock_is_local" and
>   its offset) be controllable separately from the timezone used in other
>   drivers?

For the discussion, I'm not sure I'd call this NTP timewarp, but maybe
systohc rtc offset is more clear?

Its really not connected to NTP, except that we only want to
automatically sync the RTC to the system clock when we know the system
clock is right (and that signal comes from NTP).


> * If we want keep having a way to set the sys_tz, what interface
> should that use?
>
>   Suggestions so far include
>    - adding a clock_settimeofday_time64() syscall on all 32-bit architectures to
>      maintain the traditional behavior,

If the answer to #1 above is no, we want to preserve the
functionality, then I think this is probably the best solution.
Alternatively one could add a new syscall/sysctrl that just sets the
timezone, but most 64 bit architectures already have
clock_settimeofday_time64() equiv call, so this is probably the least
duplicative.

>    - adding a sysctl interface for accessing sys_tz.tz_tminuteswest,
>    - using a new field in 'struct timex' for the timewarp offset, and

I'd push back on this one. The timewarp offset is really a RTC offset,
and has nothing to do with ntp, so we shoudn't be adding things to
adjtimex about it.

>    - adding an ioctl command on /dev/rtc/ to control the timewarp
>      offset of that particular device.

If the answer to #1 above is yes, then I think this makes more sense
to me, since the offset is a property of how we interpret the RTC (ie:
is it UTC or local time).

Getting more aggressive, from irc discussions, it sounded like
Alexandre would like to deprecate the in-kernel systohc and hctosys
logic, so if that were the case, and the answer to #1 above was yes,
then we could probably skip all of this and just drop systohc work and
keep the UTC/local logic to userland.

thanks
-john