<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 23, 2016 at 10:05 PM, Hal Murray <span dir="ltr"><<a href="mailto:hmurray@megapathdsl.net" target="_blank">hmurray@megapathdsl.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br></span>--------<br>
<br>
Is this a good time to setup a procedure for second class refclocks?  Or<br>
think about how to do it?<br>
<br>
I haven't given this a lot of thought.  The idea is to make it easy to add<br>
drivers for hardware we don't support directly.<br>
<br>
I think there are two things we would have to do.  One is keep track of<br>
names.  The other is to setup and document a recipe for adding a driver.<br>
<br>
Handwave.  My straw man is that the keep-track of numbers part means that we<br>
maintain everything but the code and documentation for a driver.  I think<br>
that's just a table entry in pylib/refclock.py and another in<br>
ntpd/refclock_conf.c  It would be nice to teach waf to make man/web pages for<br>
optional drivers.<br>
<br>
It's possible that some git magic would simplify most of that, but I don't<br>
know how to do it.  Maybe we just maintain a comment that git can replace.  ??<br>
<br>
If you use dumbclock as an example, I'll adopt the IRIG driver as a sanity<br>
check.<br><div class=""><div class="h5"><br></div></div></blockquote><div> </div><div>I figured any of these would emulate GPSD in some way and the *server* directive would be used to identify the source.<br></div><div><br></div><div>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.</div><div><br></div><div>The rest would be updates to the time.  I figure this will be SHM or socket.  </div><div><br></div><div>Clark</div></div></div></div>