Removing the worst cruft

[Clark B. Wierda]

On Sat, Jul 23, 2016 at 10:05 PM, Hal Murray <hmurray at megapathdsl.net>
wrote:

>
> --------
>
> Is this a good time to setup a procedure for second class refclocks?  Or
> think about how to do it?
>
> I haven't given this a lot of thought.  The idea is to make it easy to add
> drivers for hardware we don't support directly.
>
> I think there are two things we would have to do.  One is keep track of
> names.  The other is to setup and document a recipe for adding a driver.
>
> Handwave.  My straw man is that the keep-track of numbers part means that
> we
> maintain everything but the code and documentation for a driver.  I think
> that's just a table entry in pylib/refclock.py and another in
> ntpd/refclock_conf.c  It would be nice to teach waf to make man/web pages
> for
> optional drivers.
>
> It's possible that some git magic would simplify most of that, but I don't
> know how to do it.  Maybe we just maintain a comment that git can
> replace.  ??
>
> If you use dumbclock as an example, I'll adopt the IRIG driver as a sanity
> check.
>
>
I figured any of these would emulate GPSD in some way and the *server*
directive would be used to identify the source.

More deterministically, I would define an API for an external refclock to
"register" with the daemon.  This would include an identifying string and
any static values we would like to know.  Likely, these would be needed for
zero-config and desired otherwise.

The rest would be updates to the time.  I figure this will be SHM or
socket.

Clark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160723/6ba54624/attachment.html>