Re: [PATCH RFC V2 3/6] time: keep track of the pending utc/tai threshold

From: John Stultz
Date: Mon May 21 2012 - 14:26:42 EST


On 05/18/2012 07:09 AM, Richard Cochran wrote:
This patch introduces time keeping variables to track the next
mini-epoch between the UTC and TAI timescales. A leap second occurs
one second before a mini-epoch. When no leap second is pending, then
the epoch is set to the far future, LONG_MAX.

This code will become useful later on for providing correct time
surrounding a leap second.

Signed-off-by: Richard Cochran<richardcochran@xxxxxxxxx>
---
kernel/time/timekeeping.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index d66b213..ac04de4 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -70,6 +70,19 @@ struct timekeeper {
/* The raw monotonic time for the CLOCK_MONOTONIC_RAW posix clock. */
struct timespec raw_time;

+ /* The current TAI - UTC offset */
+ time_t tai_offset;
+ /* The UTC time of the next leap second epoch */
+ time_t utc_epoch;
+ /* Tracks where we stand with regard to leap the second epoch. */
+ enum {
+ LEAP_IDLE,
+ LEAP_INS_PENDING,
+ LEAP_INS_DONE,
+ LEAP_DEL_PENDING,
+ LEAP_DEL_DONE,
+ } leap_state;
+
One other thing, I'd rather you break this patch set up logically as:
1) Move tai offset management into timeekeeping core
2) Move leap_state managment into timekeeping core.

Instead of:
1) Add unused values to timekeeper for tai and leapstate
2) Convert NTP code to use both these new values

I know its a pain to refactor a patch set in this way, but it makes it much more clear as to what each patch is doing and the complexity of each step.

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/