[ntp:hackers] Questions on refclock to ntpd interface
Hal Murray
hmurray at megapathdsl.net
Mon Aug 20 05:40:41 UTC 2007
I'm trying to understand how refclock drivers do and/or should work.
I'm interested in the case where the device automatically sends a packet
every second.
Take the NMEA driver for example. Assuming the device is setup correctly
(aka send every second), the normal case goes like this:
Each second, the receive routine gets called with a new packet. It calls
refclock_process to add the new sample to a fifo.
When the poll routine gets called, it just sets a flag.
The next time the receive routine is called, it notices the flag and calls
refclock_report to actually process the data in the fifo.
Is there a reason to shift the call to refclock_report from poll to receive?
Is there some magic I don't know about in the context? Am I only allowed to
call refclock_report from receive routines and not from poll routines?
Doing that context switch looks like an unnecessary complication to me, but
maybe that's just the way my head works. The poll routine has to handle the
timeout case anyway, so you have to flip between two chunks of code to figure
out what's going on.
The comment at the top of the poll routine says:
* We go to great pains to avoid changing state here, since there may be
* more than one eavesdropper receiving the same timecode.
That looks interesting, but I can't figure out what it means and/or what
problem it is avoiding.
There is only one thread. Right? I think there is a signal when a packet
arrives, but I think this level of code is protected from that sort of
complication.
--
These are my opinions, not necessarily my employer's. I hate spam.
More information about the hackers
mailing list