> Sorry for causing confusion, but please understand "a hardware clock
> with timestamping capabilities than can be used for PTP support"
> whenever I wrote "PTP" or "PTP clock."
Ok that makes sense.
>
> Well, what I just said is not entirely true.
> most are bound to the PTP protocol. That may change in the future...
Which seems fine to me too - its an implementation detail of that time
source.
> > Specialist applications will presumably need to know which time source or
> > sources they are tracking and synchronizing too out of multiple potential
> > PTP sources
>
> Yes, the PTPd will have some special knowledge.
Not only that but consumers of different time synchronizations will need
to be able to describe which time source they want to talk about from a
selection of PTP or similar things.
> > system time bimble track a source makes sense just as with NTP but making
> > it a new clock seems the wrong model extending a non-too-bright API when
> > you can just put the time sources in a file tree.
>
> Don't get your meaning here, what did you mean by "file tree?"
Something like
/sys/class/timesource/<name>/...
at which point we don't have to enumerate them all, add special system
calls and then fret about the fact you can't access them from things like
shell scripts.
The fact SYS5.4 Unix and SuS got obsessed with numbering things
rather than using names unlike Unix doesn't mean it's the right model to
number them - usually the reverse is true, a heirarchy of file names is
rather more future proof.
Alan
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
