PPS documentation

[Achim Gratz]

Eric S. Raymond writes:
> I just grepped for hardpps and found a world of previously
> undocumented complications.
>
> By 'hardpps' do you mean the RFC1589 facility?

Yes, that's what the RFC1589 implementation is called on Linux, based on
the API function.  That interface was created _after_ the RFC2783
implementation interestingly enough (I had previously assumed it was
there first, but I was mistaken about that).

https://lwn.net/Articles/317560/
https://lwn.net/Articles/373193/

> Are there really two *different* APIs for kernel PPS, one defined by
> RFC2783 and one by RFC1589, or is the RFC2783 implemented in terms of
> RFC1589 on systems that have the latter?

Yes.  They should be functionally equivalent, yet still have different
API.  RFC1589 apparently was the result from the nanokernel work.
RFC2783 cleaned that up into a more portable API.  It is unclear if both
API were supposed to coexist indefinately, but.

> How is RFC2783 implemented on a tickess kernel?

The same, it just doesn't implement the optional kernel PLL interface at
all and hardpps isn't compiled since it ties into the global tick.  It
is high time that was instead implemented in the LinuxPPS framework
(using a dedicated periodic kernel timer), but I don't see any recent
activity on that front.

Classic NTP seems to have removed some of the support for PPS API
implementations that do not also implement the optional kernel consumer,
but it's entirely unclear if that was intentional or not:

http://bugs.ntp.org/show_bug.cgi?id=3367


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada