[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1323879832.6805.24.camel@work-vm>
Date: Wed, 14 Dec 2011 08:23:52 -0800
From: john stultz <johnstul@...ibm.com>
To: Richard Cochran <richardcochran@...il.com>
Cc: Andy Lutomirski <luto@...capital.net>,
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>
Subject: Re: [RFC 0/2] ABI for clock_gettime_ns
On Wed, 2011-12-14 at 08:20 +0100, Richard Cochran wrote:
> On Mon, Dec 12, 2011 at 07:43:02PM -0800, john stultz wrote:
> >
> > Having a CLOCK_TAI would be interesting across the board. We already
> > keep a TAI offset in the ntp code. However, I'm not sure if ntp actually
> > sets it these days.
>
> A bit OT, but what do think of the idea of keeping TAI in the kernel,
> and providing UTC via a tabular conversion routine?
Agreed its OT for this thread.
> Michel Hack wrote an article last year detailing how Linux botches the
> leap second and suggested a more robust way to handle it.
Hmm. Do you have a link to the article?
I like the idea of having TAI as a kernel clockid. The hard part is
getting systems to initialize it properly at boot.
Also part of the issue with leapseconds is that time functions are such
a hot path, we can't really add extra conditionals checking for leap
seconds. Instead the leapsecond occurs on the first tick of the
leapsecond.
More interestingly to me is Google's recent use of slewed leapseconds.
However, how that would work on a public network is a bit more fuzzy.
And being able to support both TAI and slewed leapseconds would require
quite a bit more logic.
thanks
-john
--
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