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

[John Stultz <john.stultz@linaro.org>]

On 05/03/2012 12:28 PM, Richard Cochran wrote:
> On Thu, May 03, 2012 at 11:44:45AM -0700, John Stultz wrote:
>> But the changes you make to getnstimeofday() still needs to happen
>> in the vDSO code. The vDSO code basically implements
>> getnstimeofday() in userland.
>>
>> If you're code is trying to make it so that the leap-second is
>> properly handled at the second boundary instead of the tick
>> boundary, there must me some change needed to the vDSO, since the
>> vDSO code is updated only each tick. Otherwise how can you enforce
>> the leap after the second boundary but before the tick?
> Yeah, so the vDSO does the sub-tick interpolation, and this can easily
> miss an inserted leap second for a while (just like the current code).
>
> So, this patch series as it stands improves the users of the
> traditional syscalls without hurting the superduper vDSO performance
> at all. The vDSO leap second time errors are not fixed, but they are
> also no worse than today, either.
>
> I am try to say that, even if there is resistance to adding code in
> the vDSO path for reasons of performance, that doesn't necessarily
> mean that we cannot fix the leap second for the tradition syscall
> case.
But this also has the same drawback of only fixing the adjtimex() path, 
in that applications that mix calls to gettimeofday or adjtimex will see 
different behavior in that tick interval.  I'd also try to avoid any 
disparity between the syscall and vdso syscall implementations, as 
they're supposed to be identical.

thanks
-john