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

[Richard Cochran <richardcochran@gmail.com>]

On Thu, May 03, 2012 at 12:57:40PM -0700, John Stultz wrote:
> On 04/27/2012 01:12 AM, Richard Cochran wrote:
> >
> >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.

It really isn't a layer. It is just a pair of static inline helper
functions. The code could just as well be internal to timekeeper.c,
but I put it in its own file so that I could include it into a unit
test program.

> 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.

So, is this a "won't fix" issue, in your view?

(If so, I'll drop it.)
 
> Take a look at it and let me know what you think.

It looks okay to me, as far as it goes.

At least you offer a clock that doesn't jump around. With your patches
(and the TAI offset fix before), user space programs sensitive to the
leap second uglies would have a reasonable option. Data collection
programs can read and store TAI time stamps, and these can always be
converted into UTC using a table method.

But do you think it will be possible to implement the following in the
same way?

- clock_settime(CLOCK_TAI)
- clock_adjtime(CLOCK_TAI)
- timer_create(CLOCK_TAI)

Thanks,
Richard