On Tue, Aug 13, 2019 at 2:06 AM Arnd Bergmann <a...@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