[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101226141447.GA4830@riccoc20.at.omicron.at>
Date: Sun, 26 Dec 2010 15:14:47 +0100
From: Richard Cochran <richardcochran@...il.com>
To: "Kuwahara,T." <6vvetjsrt26xsrzlh1z0zn4d2grdah@...il.com>
Cc: john stultz <johnstul@...ibm.com>, linux-kernel@...r.kernel.org,
linux-api@...r.kernel.org, netdev@...r.kernel.org,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Arnd Bergmann <arnd@...db.de>,
Christoph Lameter <cl@...ux.com>,
David Miller <davem@...emloft.net>,
Krzysztof Halasa <khc@...waw.pl>,
Peter Zijlstra <peterz@...radead.org>,
Rodolfo Giometti <giometti@...ux.it>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH V7 1/8] ntp: add ADJ_SETOFFSET mode bit
On Sun, Dec 26, 2010 at 05:38:57AM +0900, Kuwahara,T. wrote:
> After all, I'd prefer your earlier patchset. Leaving aside the
> compatibility issue, there's no particular reason we have to re-use
> the struct timex, which requires otherwise unnecessary conditional
> branches as well as unit conversions. Don't you agree?
Well, from my point of view of wanting to allow a user space clock
servo to be able to adjust a hardware clock, it would be sufficient to
offer a way to jump the clock and to adjust the frequency via one or
perhaps two new system calls.
That is indeed what I first suggested, and I still think it would be a
clean and simple interface. The NTP call is quite gross, since it
multiplexes a whole bunch of different functions through the timex
structure.
However, several reviewers on the lkml prefered to keep with the NTP
interface. It offers the needed functionality and is already well
established, despite its ugliness.
To me, the proposed ADJ_SETOFFSET is a simple and logical extenstion
of the NTP interface. Also, the implementation is straightforward. In
contrast, using a special -INF value seems a bit obtuse to me.
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists