From: John Stultz <john.stultz@linaro.org>
To: "Kuwahara,T." <6vvetjsrt26xsrzlh1z0zn4d2grdah@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Richard Cochran <richardcochran@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Richard Cochran <richard.cochran@omicron.at>
Subject: Re: [PATCH 2/3] ntp: add ADJ_SETOFFSET mode bit
Date: Mon, 03 Jan 2011 12:44:26 -0800 [thread overview]
Message-ID: <1294087466.2571.89.camel@work-vm> (raw)
In-Reply-To: <AANLkTi=LqkC-tKzbb6y=iL0UvFYcfcHSuX=jVVFCk1uR@mail.gmail.com>
On Wed, 2010-12-29 at 05:47 +0900, Kuwahara,T. wrote:
> On Tue, Dec 28, 2010 at 8:40 AM, John Stultz <john.stultz@linaro.org> wrote:
> > From: Richard Cochran <richardcochran@gmail.com>
> >
> > This patch adds a new mode bit into the timex structure. When set, the
> > bit instructs the kernel to add the given time value to the current time.
>
> I came up with this simple solution: "Just use ADJ_OFFSET as usual,
> but don't forget to disable the kernel PLL."
Again, this seems to be trying to add new functionality into a corner
case of a existing mode.
I don't like this because it makes testing and validating that the code
is correct for its uses difficult. Especially given that a number of
combinations of modes might be set at once. What happens to freq
adjustments done at the same time as an ADJ_OFFSET - STA_PLL?
Personally, I see the adjtimex call as too flexible, as I'd prefer to
have the modes be exclusive (adjusting one thing per call). As it is
now, the kernel doesn't throw out enough invalid to invalid-ish cases.
ie: MOD_NANO|MOD_MICRO: totally cool! We should fix these and make the
input checking more strict, but in my mind moving to mode-numbers rather
then mode-flags would be much nicer (and more extendable).
Richard: Maybe this is a good thing to think about for clock_adjtime? If
we are adding a new syscall, maybe we should make sure we clean up some
of the old syscalls issues? It does add a good bit of complexity, as the
idea of clock_adjtime being a multiplexing adjtimex was nice and simple.
We'd also have to review the mode usage to see if multi-mode adjustments
in a single call are all that common or not.
Kuwahara: Maybe could you maybe better explain your passion against
using a new mode-flag for this new functionality? You seem dead set
against it, but have not expressed your rational well.
thanks
-john
next prev parent reply other threads:[~2011-01-03 20:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-27 23:40 [PATCH 0/3] Cleanup ADJ_SETOFFSET patch John Stultz
2010-12-27 23:40 ` [PATCH 1/3] time: Introduce timekeeping_inject_offset John Stultz
2010-12-27 23:40 ` [PATCH 2/3] ntp: add ADJ_SETOFFSET mode bit John Stultz
2010-12-28 20:47 ` Kuwahara,T.
2011-01-03 20:44 ` John Stultz [this message]
2011-01-04 8:37 ` Richard Cochran
2011-01-04 19:08 ` John Stultz
[not found] ` <12d52d09b05.7801197194177918524.-8125715123212004756@gmail.com>
2011-01-05 7:00 ` Richard Cochran
2011-01-04 8:40 ` Richard Cochran
2011-01-04 19:14 ` John Stultz
2010-12-27 23:40 ` [PATCH 3/3] ntp: Change ADJ_SETOFFSET implementation to use timekeeping_inject_offset John Stultz
2010-12-28 11:20 ` [PATCH 0/3] Cleanup ADJ_SETOFFSET patch Richard Cochran
2010-12-28 12:53 ` Richard Cochran
2010-12-28 13:36 ` 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=1294087466.2571.89.camel@work-vm \
--to=john.stultz@linaro.org \
--cc=6vvetjsrt26xsrzlh1z0zn4d2grdah@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=richard.cochran@omicron.at \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox