Message-ID: <1323898490.6805.92.camel@work-vm>
Date:	Wed, 14 Dec 2011 13:34:50 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Richard Cochran <richardcochran@...il.com>,
	linux-kernel@...r.kernel.org, Kumar Sundararajan <kumar@...com>,
	Arun Sharma <asharma@...com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steve Allen <sla@...lick.org>
Subject: Re: [RFC 0/2] ABI for clock_gettime_ns

On Wed, 2011-12-14 at 11:20 -0800, Andy Lutomirski wrote:
> On Wed, Dec 14, 2011 at 11:07 AM, john stultz <johnstul@...ibm.com> wrote:
> > I don't see a reason to limit clock_gettime_ns() to only CLOCK_TAI.
> > After all, while CLOCK_TAI doesn't have leapseconds, it still can be set
> > by userland if its wrong, so it doesn't provide the same functionality
> > as CLOCK_MONOTONIC. Additionally, the motivation for this new interface
> > is for a more efficient CLOCK_THREAD_CPUTIME vdso implementation, so an
> > exclusive CLOCK_TAI interface wouldn't serve that need.
> >
> > I agree adding CLOCK_TAI is an interesting feature, but that could done
> > properly with the existing clock_gettime() interface. So I think the
> > CLOCK_TAI discussion is really disconnected from the new ABI being
> > proposed.
> 
> Unless we want the future CLOCK_TAI to also return the UTC offset (or
> vice versa), in which case we can use 32 bits of the padding field for
> exactly that purpose.  (If TAI and UTC diverge by more than 2^32
> seconds, we probably have other things to worry about.  That being
> said, it might be useful to add a little more padding at the cost of a
> bit of performance.)

FYI: Interesting additional emails from Steve Allen below (forwarded
with permission) that put some caution around CLOCK_TAI. 

Also, The timescales web page looks like a great reference, which I'll
have to bookmark.

thanks
-john


-------- Forwarded Message --------
From: Steve Allen <sla@...lick.org>
To: John Stultz <johnstul@...ibm.com>
Subject: TAI in linux kernel
Date: Wed, 14 Dec 2011 11:44:23 -0800

Greetings John Stultz,

I note the linux kernel discussion mentioning the use of TAI.

It may be relevant to note the position of the CCTF and BIPM on
the use of TAI as expressed in Document CCTF/09-27

http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UTC-ITU-R.pdf

Their position is that they do not want TAI used as an operational
system time, and in their last paragraph they make it plain that
they would consider suppressing TAI in order to accomplish that.

Building TAI into the linux kernel could result in the use of
an nonexistent time standard.



-------- Forwarded Message --------
From: Steve Allen <sla@...lick.org>
To: john stultz <johnstul@...ibm.com>
Subject: Re: TAI in linux kernel
Date: Wed, 14 Dec 2011 12:33:40 -0800

Greetings again John,

On Wed 2011-12-14T12:11:52 -0800, Steve Allen hath writ:
> Feel free.  It's a BIPM document, and somewhat confusing because BIPM
> documents from a few years earlier indicated different things, so it's
> hard to tell what to rely upon when designing operational systems.

I have been trying to track what's what for quite a while.

For a few links pointing at previous position statements about TAI see
http://www.ucolick.org/~sla/leapsecs/timescales.html#TAI
The 1999 statement is quite opposite to the 2007/2009 document.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists