Poul-Henning Kamp wrote on 2005-08-01 11:26 UTC:
> The NTP kernel support will allow leapseconds on any midnight, but the
> NTP daemon is more strict.
Adding the missing test-override option to xntpd doesn't sound like a
really major engineering exercise.
I never liked the narrow-minded end-of-day leap flags in the current
adjtimex(). I hope this API will one day be replaced by a much simpler
and more generic one.
The sort of kernel clock driver API I have in mind uses three variables
to control leap seconds:
time_t next_leap; /* marks the end of the next leap second
(traditionally next_leap == YYYY-{01,07}-01T00:00:00Z),
ignored if next_leap_len == 0 */
int next_leap_len; /* 0: no next leap announced yet
+1: insert one second right before time == next_leap
-1: skip one second right before time == next_leap */
int leap_adjustment_duration; /* number of seconds before the end of the next
leap second, over which the time_t clock
frequency will be adjusted to perform the
phase step caused by the leap second.
Recommended value:
next_leap_duration == 1000 (UTS, 0.1% freq error)
*/
Advantages:
- simpler, actually reduces the lines of code in the kernel
- more flexible, less likely to need modification due to future UTC policy changes
- easier to test
- API permits gentle UTS-style insertion of leap second that minimizes
disruption to active real-time processes, though the existing
very unfriendly non-monotonic kernel behaviour can still be
requested by leap_adjustment_duration = 0.
- [API permits natural extionsion for double leap-seconds through |next_leap_len| > 1
(not required for the next ~60000 years though ;-]
Anything else is - in my eyes - an unwise choice on the policy versus
mechanism front.
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Received on Mon Aug 01 2005 - 05:18:21 PDT