lkml.org 
[lkml]   [2010]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
> To tell the truth, my original motivation for the patch set was to
> support PTP clocks and applications. I don't think that is such a bad

ptp *clocks*

> idea. After all, the adjtimex interface was added just to support NTP.
>
> At the same time, I can understand the desire to have a generic
> hardware clock adjustment API. Let me see if I can understand and
> summarize what people are asking for:
>
> clock_adjtime(clockid_t id, struct timex *t);
>
> and struct timex gets some new fields at the end.

For a new syscall you could equally make it

(clockid_t id, void *args)

> Using the call, NTPd can call clock_adjtime(CLOCK_REALTIME) and PTPd
> can call clock_realtime(CLOCK_PTP) and everyone is happy, no?

If you only have one clock that you are calling 'the PTP clock' - but is
that a good assumption ?

I agree with your fundamental arguments as I understand them

- That it's another clock or clocks possibly not synchronized with the
system clock

- That there should be a sensible API for doing slews and steps on other
clocks but the systen clock.

I'm concerned about the assumption that there is a single magic PTP
clock, and calling it a PTP clock for two reasons

- There can be more than one

- PTP is just a protocol, in five years time it might be TICTOC or
something newer and more wonderous, in some environments it'll be a
synchronous distributed clock generation not PTP etc. Wiring PTP or
IEE1588v2 into the clock name doesn't make sense.

I'd be happier with a model which says we have some arbitary number of
synchronization sources which may or may not have a connection to system
time, and may be using all sorts of synchronization methods. Clock in
fact seems almost a misnomer.

Alan




\
 
 \ /
  Last update: 2010-08-27 16:35    [W:0.102 / U:3.112 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site