Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp8184ybl; Tue, 13 Aug 2019 14:49:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqwHzGn9RbDheInbjB3dZhgHusSjWisTmM9Jfhf5/hsBfDrm27fi6qJuaUEtso6/VIDrQhCo X-Received: by 2002:a17:90b:8c1:: with SMTP id ds1mr4215916pjb.114.1565732946068; Tue, 13 Aug 2019 14:49:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565732946; cv=none; d=google.com; s=arc-20160816; b=Hr0eFTxc5H8sUNEws90pPGsi8YreL4+ZL1X3h7LS89v8La+604MTVi86WFlo+i76rX C6H1V/WuyfqPbtLUo6+p4mH0sB+XApodhxDY4ztSIdNlXWmhVpPzSpWnxudUATUNB2Af r4XxOeKG1lRl5xz7fq4Ahft72x2G9X1eaVsox4ZcT9C3g+yCGoj5Oq3cjNUiU3R+/9l5 IEke5DbTIe5ehl4DKVZ6S9FIzDlHS0MSsF5hPHaw0fnn3O6UFD2dckK/Oh0448C8E7T5 ElfC8QU8/v36mGWOETl+iCiYkbEZr5Gm26hqrR+raazZkjom+QgO4JKuy2oev+QdnA5Q 03GQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=JD7rgjlcUVeA2QIRHrr5OELZvKlgU5bNzgf6N/ZcPFQ=; b=gFxWqij+kFMznrk479ssD6uyRHLHUnwPRcpN8v6/Z34K2B6bBrBYt1uawaIUrs2syo MZtJD1LO8GLaeQjsXtF+O30VcSwiYTMhtlXSBE8Wuat4eA/XQ6Mcx98huuCQ0qiol6sd 6/ssqIVirBfgMyFZjqOesqSbwEhMF//XFnezZeg672IK/VUWRZ3MivtyON7rOlrBUa33 BYRfg2S617oRHLNLkBoXoigt78HY+uQtvZCspAkL8qUc2Ea35pbLosEEiG3qniGkC8s8 WvUv5NoV6OC1YzPltEfY05oDuZ5lnT9dbSpKwujW4tkezM7T1y61t6E/kJHzOXWsprIN PsaA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j190si68046075pge.92.2019.08.13.14.48.50; Tue, 13 Aug 2019 14:49:06 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726980AbfHMVp6 (ORCPT + 99 others); Tue, 13 Aug 2019 17:45:58 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:43141 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725903AbfHMVp5 (ORCPT ); Tue, 13 Aug 2019 17:45:57 -0400 X-Originating-IP: 90.65.161.137 Received: from localhost (lfbn-1-1545-137.w90-65.abo.wanadoo.fr [90.65.161.137]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id C9F8E60003; Tue, 13 Aug 2019 21:45:52 +0000 (UTC) Date: Tue, 13 Aug 2019 23:45:52 +0200 From: Alexandre Belloni To: John Stultz Cc: Arnd Bergmann , Linux Kernel Mailing List , Thomas Gleixner , Stephen Boyd , Florian Weimer , Linus Torvalds , Theodore Ts'o , "H. Peter Anvin" , Palmer Dabbelt , Alistair Francis , GNU C Library , Karel Zak , Lennart Poettering , OGAWA Hirofumi Subject: Re: New kernel interface for sys_tz and timewarp? Message-ID: <20190813214552.GD3600@piout.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/08/2019 10:10:53-0700, John Stultz wrote: > On Tue, Aug 13, 2019 at 2:06 AM Arnd Bergmann 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). > Well, the only function in systohc.c is rtc_set_ntp_time and its only user is kernel/time/ntp.c. That why I suggested on IRC to move it to the kernel timekeeping instead of having it in the rtc subsystem. Also, this function only works properly on systems with an MC146818 compatible RTC. > > > * 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). > The main issue I have with that is that while the offset is possibly specific to an RTC, it is something that is not used by the rtc subsystem as this offset handling is done by the caller. i.e. hwclock handles local time vs UTC time. That is why sync_rtc_clock also had to do it. It would be awkward to have different paths in the rtc core depending on whether the set_time call is coming from userspace or the kernel. > 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. > My point is that userspace has all the necessary info to do a correct job. It is even more flexible because currently the kernel is limited to the rtc selected at compile time (this often ends up being rtc0 which may or may not be functional or battery backed) and the 11 minute interval is fixed. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com