All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Richard Cochran <richardcochran@gmail.com>
Cc: linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH RFC V2 4/6] time: introduce leap second functional interface
Date: Mon, 21 May 2012 13:24:57 -0700	[thread overview]
Message-ID: <4FBAA499.1070905@linaro.org> (raw)
In-Reply-To: <20120521191844.GC19812@netboy.at.omicron.at>

On 05/21/2012 12:18 PM, Richard Cochran wrote:
> On Mon, May 21, 2012 at 11:01:03AM -0700, John Stultz wrote:
>> On 05/18/2012 07:09 AM, Richard Cochran wrote:
>>> +
>>> +int timekeeping_gettod_status(struct timespec *ts, time_t *offset);
>>> +
>>> +void timekeeping_delete_leap_second(void);
>>> +
>>> +void timekeeping_finish_leap_second(void);
>>> +
>>> +void timekeeping_insert_leap_second(void);
>>> +
>>> +#endif
>> Why not just add these to time.h?
> This is a private interface only for ntp.c, not for the whole rest of
> the kernel via time.h.
Hrm.  I prefer to keep things fairly flat (even having time.h and 
timex.h bugs me somewhat).  But having such a separation could be 
useful, but maybe at a slightly more coarse level. Something like 
timekeeping-internal.h and time.h, splitting all the general accessors 
away from the non-general.

I just don't want to have a ton of stray .h files, but maybe I'm 
prematurely worrying about it.

> BTW this highlights the very icky incestuous relationship between
> ntp.c and timekeeper.c. Probably there should be a comment documenting
> the (unspoken) locking sequence for ntp_lock and timekeeper.lock.
>
The locking order is pretty straight forward: timekeeper.lock -> 
ntp_lock.   This only gets messy when you require timekeeping data from 
the ntp context, but usually we provide the required data via the 
caller.  But better documentation is always welcome.

thanks
-john


  reply	other threads:[~2012-05-21 20:25 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-18 14:09 [PATCH RFC V2 0/6] Fix leap seconds and add tai clock Richard Cochran
2012-05-18 14:09 ` [PATCH RFC V2 1/6] time: remove obsolete declaration Richard Cochran
2012-05-21 23:57   ` John Stultz
2012-05-18 14:09 ` [PATCH RFC V2 2/6] ntp: remove useless parameter Richard Cochran
2012-05-21 23:58   ` John Stultz
2012-05-18 14:09 ` [PATCH RFC V2 3/6] time: keep track of the pending utc/tai threshold Richard Cochran
2012-05-21 18:09   ` John Stultz
2012-05-21 19:08     ` Richard Cochran
2012-05-22 17:39       ` Richard Cochran
2012-05-22 18:06         ` John Stultz
2012-05-23  8:29           ` Richard Cochran
2012-05-23 16:50             ` John Stultz
2012-05-23 19:17               ` Richard Cochran
2012-05-23 20:18                 ` John Stultz
2012-05-24  6:43                   ` Richard Cochran
2012-05-24  6:57                     ` Richard Cochran
2012-05-26 15:07                       ` Richard Cochran
2012-05-30  1:46                       ` John Stultz
2012-05-30  1:49                         ` John Stultz
2012-05-30  5:11                           ` Richard Cochran
2012-05-30  5:56                             ` John Stultz
2012-05-30  6:19                               ` Richard Cochran
2012-05-30  6:23                                 ` John Stultz
2012-05-30  7:27                                   ` Richard Cochran
2012-05-23 19:42               ` Richard Cochran
2012-05-21 18:21   ` John Stultz
2012-05-21 19:13     ` Richard Cochran
2012-05-18 14:09 ` [PATCH RFC V2 4/6] time: introduce leap second functional interface Richard Cochran
2012-05-21 18:01   ` John Stultz
2012-05-21 19:18     ` Richard Cochran
2012-05-21 20:24       ` John Stultz [this message]
2012-05-22  4:25         ` Richard Cochran
2012-05-22 15:10           ` John Stultz
2012-05-18 14:09 ` [PATCH RFC V2 5/6] time: move leap second management into time keeping core Richard Cochran
2012-05-21 18:18   ` John Stultz
2012-05-21 19:24     ` Richard Cochran
2012-05-18 14:09 ` [PATCH RFC V2 6/6] time: Add CLOCK_TAI clockid Richard Cochran

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FBAA499.1070905@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.