Re: [PATCH RFC V1 0/5] Rationalize time keeping

[John Stultz]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/