[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101222071104.GA8627@riccoc20.at.omicron.at>
Date: Wed, 22 Dec 2010 08:11:04 +0100
From: Richard Cochran <richardcochran@...il.com>
To: john stultz <johnstul@...ibm.com>
Cc: "Kuwahara,T." <6vvetjsrt26xsrzlh1z0zn4d2grdah@...il.com>,
Alexander Gordeev <lasaine@....cs.msu.su>,
Rodolfo Giometti <giometti@...eenne.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 Tue, Dec 21, 2010 at 01:59:44PM -0800, john stultz wrote:
> However, your concern does bring up a good point: 0x40 is MOD_PPSMAX in
> BSD, and we should at-least check to make sure that the PPS code that is
> currently floating around on the lists and is in akpm's tree hasn't
> already reserved that bit.
If the concern is only about that bit, then we can choose another one
from the range 0x0f00 instead.
It seems to me that the ability to jump the clock is a very useful
feature, at least when implementing a clock servo for PTP in user
space, if not in other cases, too. I wonder why that option is missing
from the interface in the first place.
I am not aware of any serious attempt to get any kind of standardized
PTP clock support into any other OS. As far as compatibility with NTP
is concerned, why can't we let Linux set an example and let
NTP/BSD/*nix follow us?
Richard
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists