Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 26 Mar 2021 20:28:59 -0700
From:   Richard Cochran <richardcochran@gmail.com>
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Daphne Preston-Kendall <dpk@nonceword.org>,
        LKML <linux-kernel@vger.kernel.org>,
        John Stultz <john.stultz@linaro.org>,
        Miroslav Lichvar <mlichvar@redhat.com>,
        "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Subject: Re: [Bug 212265] New: clock_gettime(CLOCK_TAI, ...) should return an
 error when TAI has not been configured
Message-ID: <20210327032859.GA3168@hoboy.vegasvil.org>
References: <87sg4iupzs.fsf@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87sg4iupzs.fsf@nanos.tec.linutronix.de>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Fri, Mar 26, 2021 at 12:13:43PM +0100, Thomas Gleixner wrote:
> On Sat, Mar 13 2021 at 17:44, bugzilla-daemon wrote:
> > Unfortunately, although the majority of distributions ship with a leap
> > second file from the zoneinfo database, many or most of them (I have
> > Arch here) do not configure ntpd to know about it, so ntpd does not
> > set things up properly for CLOCK_TAI to work.

I'm not sure about "many or most" distros.  In Debian, the ntp package
depends on tzdata, and the default /etc/ntp.conf does use the leap
seconds file.

> That would be a user visible change and might hit existing user space by
> surprise, so that's not a necessarily a good option.

Agreed.
 
> and the kernel on it's own has no way to check for and retrieve an
> up-to-date version. That's why it is delegated to user space.

Right, the kernel can't make any assumptions about the TAI-UTC offset.

> I hope the NTP/TAI wizards have some more insight/opinions on this.

I agree that ntpd and the current distros don't handle this very well,
but all the pieces are there to allow user space to handle TAI and
leap seconds as reasonably as possible.  The fundamental issue is that
there is no way to determine the TAI-UTC offset without some kind of
input from the real world.

Even with GPS, after a cold boot you cannot know the offset
immediately, because the leap second information is broadcast in the
almanac only every 12.5 minutes, and so you can be left in suspense
for a long time.

Using ntpd on Debian, the service will set the offset, but only after
synchronization with the upstream server has been established, and
this takes about five minutes, IIRC.

If waiting 5 or 12.5 minutes is too long for your requirements, you
can boot strap the time from RTC [1] and then consult the leap seconds
table [2] to set the TAI-UTC offset in the kernel via adjtimex().

Unfortunately there is no user space utility for setting TAI-UTC, but
I hacked one 'adjtimex' program for this purpose:

    https://github.com/richardcochran/ntpclient-2015

Getting back to the original point of the kernel returning an error,
I don't see a need for this.  Applications that require correct leap
seconds can simply call adjtimex() and wait until the initial zero
value is changed by ntpd/etc to the correct offset.  That isn't
fundamentally harder than calling clock_gettime() and waiting until
the error would go away.

Thanks,
Richard

1. Assuming the RTC was set and has a fresh battery, and assuming no
   leap seconds occurred while your computer was off!

2. Assuming the RTC value is not newer than the expiration date of the
   leap seconds file.