> 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev