Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp735281ybl; Wed, 14 Aug 2019 05:17:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqyRsg2x9pN4mRuy23AjIXJ1zzmQqVCsYlV3IfNPG/T9qhkCtLTjpTBgD0Si9jGgZV8OO4ND X-Received: by 2002:a63:5648:: with SMTP id g8mr37996403pgm.81.1565785037738; Wed, 14 Aug 2019 05:17:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565785037; cv=none; d=google.com; s=arc-20160816; b=nhDQWDTspvu8ycI6WH+t3TFoG6HxAUHko5VkCJiq33kPMjPXanYOh4y9rlTcv3YV7z S9VfiexheFFTGSvyEOJAVsMCJP79gE2ovIK5uFoeDadRhu4/4HHgn1nzCNlrlwVKNwVr rTh9C2jDksJkkqqPcoDomKrjnmJ5zx1Wj2WJ+fX9hxC+E3ApsIFGx7x1+L73d2fDoE7s YuCbGjulwg6D1u6NNDJh9SotnBTlUwQaB0QDKMZDZc/rJYXaUT6sJsToLsrJpW1X0AFu ahUBfJt6bF6iJLcgMmQHphapIT9t2DrThPItjBPq0M572JzmxSqf2sFXquBjnonfsrlk +KMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ynntE50k8jyQQUL/goRzR2QTANi56bK7b25iAyfUu0Q=; b=e0VSwB+sIDhuW3wIKBaFeW6+vPP9wO1PH80krG7zEN4svzq9g2o7CM5viXxY229x4S 9XfjgLYyNR+TGNvNrKhTVH0ZCy2iIxc3ouIwaAWulzDQQ2b+EtHwpUq4vsL4dBN1fdKe QKwxe0jIGqEZCrKjLJDR/evbOxwUxH9FZ6XNktVKCb1a8Vez3opFbMUncdEzrneDnMyO 0L1j6UDCeDFtWQjUNz5iMRybfyXdBkrwoI4gfegyolC7K3ghQdSO2nzAxiFlFXnUpmCn JThGBwbdhSfqyhxpVQU6KrkFYZVH3Gv6DNfsYKNFXw/5ESCFfkdM+pd0IP57fG/5CU1O KENg== 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 q13si2904966pjb.13.2019.08.14.05.16.59; Wed, 14 Aug 2019 05:17:17 -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 S1727617AbfHNMPK (ORCPT + 99 others); Wed, 14 Aug 2019 08:15:10 -0400 Received: from gardel.0pointer.net ([85.214.157.71]:35000 "EHLO gardel.0pointer.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726365AbfHNMPK (ORCPT ); Wed, 14 Aug 2019 08:15:10 -0400 Received: from gardel-login.0pointer.net (gardel.0pointer.net [85.214.157.71]) by gardel.0pointer.net (Postfix) with ESMTP id 3A57BE80937; Wed, 14 Aug 2019 14:15:08 +0200 (CEST) Received: by gardel-login.0pointer.net (Postfix, from userid 1000) id D325A160102; Wed, 14 Aug 2019 14:15:07 +0200 (CEST) Date: Wed, 14 Aug 2019 14:15:07 +0200 From: Lennart Poettering To: Alexandre Belloni Cc: Arnd Bergmann , "Theodore Y. Ts'o" , Linus Torvalds , Linux Kernel Mailing List , Thomas Gleixner , John Stultz , Stephen Boyd , Florian Weimer , "H. Peter Anvin" , Palmer Dabbelt , Alistair Francis , GNU C Library , Karel Zak , OGAWA Hirofumi Subject: Re: New kernel interface for sys_tz and timewarp? Message-ID: <20190814121507.GB10706@gardel-login> References: <20190814000622.GB20365@mit.edu> <20190814090936.GB10516@gardel-login> <20190814093208.GG3600@piout.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190814093208.GG3600@piout.net> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mi, 14.08.19 11:32, Alexandre Belloni (alexandre.belloni@bootlin.com) wrote: > 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. Sure, but 12h off is not that bad, much better than being 39years off. Moreover, it's off only for those who actually dual boot Windows and make use of the RTC-in-local-time functionality. For them having the time slightly off during early boot is not great but also not totally afwul, and the whole concept of RTC-in-local-time is not that great anyway. It's not a reason to penalize everybody else who has the RTC in UTC, as they should. > - 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 Well, but how do you think userspace would figure out which RTC to use in a way the kernel couldn't do equally well or better? On PCs at least it's very clear which RTC driver is the right one. And if non-PC hardware comes with borked RTC hw then it's probably a good idea not to compile support for such RTCs into the kernel in the first place... I know that there are some environments where RTC devices are compiled as modules. But that means they are loaded relatively late during the boot process, i.e. at a time where udevd is started and triggers all busses, but that's *very* late in most cases, and it woud suck having timestamps in early-boot logs that are 39y off until that point. I'd argue that in the vast majority of cases the person building the kernel for a device knows very well which RTC is connected to the device they are interested in, and should just build that driver in, and don't bother with userspace complexity, later userspace module loading or anything like that. Lennart -- Lennart Poettering, Berlin