Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp570956ybl; Wed, 14 Aug 2019 02:34:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqwig0bLMVC2V82Kq98ap8lrRCSeaiXnY+0DnstzPtZJRqAAMCEXKnuA98eFK9JJWJD4U1ti X-Received: by 2002:a65:5584:: with SMTP id j4mr37873505pgs.258.1565775267184; Wed, 14 Aug 2019 02:34:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565775267; cv=none; d=google.com; s=arc-20160816; b=YqEtuEYceNLUF9pTwL1KYQ8A0uJg2DhrJQfrvjg2Q9bIhev/+lCgryd6WMC2u2oFRz Ecouh5HmO7Z9ulg7pcPYVDn9Gaz/rjDU+xyk0T8GcQ6SvUzRHRhqOMqjO+8hHyJWMPgZ jNPgEDc61CLXKLtgGZUknsfTjsnXtvlYZx9gnelVggi4LFLg6bLpA2AInPejeDX3+rNW /u/Nnsujp3nc2l7ltT6zuwlS3728ptjUtgV+vcqyyAJK3p+MBT1EAWSjxmNp/+gCkkx+ KA8oVCRtIkxKcOCRxpWOZrOIuAZg0Dkk8dZNbUsMP2lpndjjdocNT2I/NppPMu0w140f ecog== 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=xFbPCNcWmc9mE7/CoEsLFrwrGhJGLeKaKcLK810P2fI=; b=H3F+mD9IbhGs+ltx4XPYpznvcW8yM4PyfG/VZDP9gNUjMB9Y4mHnu7uLortvF8+f+g aKWtM91DyGjHBmaEdb43Zy6NYDYtHVNhY2cuNW1LfLg4Az7BCdzmuMnVSkRgBebCe/sT AId+EwBw/CEd96wHGjUA9BIg439b9SDTBK1TuFHpHrbWCJ9HPN9PU2JClMIfp/WMk6UA +azoogncxrW26Ttl1ncfXuPqZ2tA6+RX1P8Xwccdl4mqUjtDRQ5pGNH3LJp0WCBUFjSs /hh4thY+ApKHQabgeHTZ7ILHYzWRHOsRwWNzUxQ4zltcY955pzJH8jYF1NeJNlCFOJxG P0HA== 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 y6si33426234pgp.320.2019.08.14.02.34.10; Wed, 14 Aug 2019 02:34:27 -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 S1726585AbfHNJcO (ORCPT + 99 others); Wed, 14 Aug 2019 05:32:14 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:50425 "EHLO relay6-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725265AbfHNJcO (ORCPT ); Wed, 14 Aug 2019 05:32:14 -0400 X-Originating-IP: 92.137.69.152 Received: from localhost (alyon-656-1-672-152.w92-137.abo.wanadoo.fr [92.137.69.152]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id A792AC0006; Wed, 14 Aug 2019 09:32:09 +0000 (UTC) Date: Wed, 14 Aug 2019 11:32:08 +0200 From: Alexandre Belloni To: Lennart Poettering 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: <20190814093208.GG3600@piout.net> References: <20190814000622.GB20365@mit.edu> <20190814090936.GB10516@gardel-login> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190814090936.GB10516@gardel-login> 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 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