[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FA2E334.7040601@linaro.org>
Date: Thu, 03 May 2012 12:57:40 -0700
From: John Stultz <john.stultz@...aro.org>
To: Richard Cochran <richardcochran@...il.com>
CC: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH RFC V1 0/5] Rationalize time keeping
On 04/27/2012 01:12 AM, Richard Cochran wrote:
> Just in time for this year's leap second, this patch series presents a
> solution for the UTC leap second mess.
>
> Of course, the POSIX UTC system is broken by design, and the Linux
> kernel cannot fix that. However, what we can do is correctly execute
> leap seconds and always report the time variables (UTC time, TAI
> offset, and leap second status) with consistency.
>
> The basic idea is to keep the internal time using a continuous
> timescale and to convert to UTC by testing the time value against the
> current threshold and adding the appropriate offset. Since the UTC
> time and the leap second status is provided on demand, this eliminates
> the need to set a timer or to constantly monitor for leap seconds, as
> was done up until now.
So as I mentioned in my earlier review of this patch set, I'm not as
excited about the meta-layer you added in utc-tai.h.
So I figured I'd give it a short go and see if a good chunk of what your
proposing could be done in a simpler way.
Please check out:
http://git.linaro.org/gitweb?p=people/jstultz/linux.git;a=shortlog;h=refs/heads/dev/clktai
The untested patch set there basically pushes TAI time management into
the timekeeping core, and then exports a CLOCK_TAI clockid.
This patch set *does not* address the tick-granularity delayed
leap-second processing issue that your patch also addresses. But I feel
like the basic handling of tai is a little simpler.
Take a look at it and let me know what you think.
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