ntpq, refclocks

[Eric S. Raymond]

Hal Murray <halmurray at sonic.net>:
> [context is ntpq via shared memory]
> 
> > Any reason not to use Unix-domain sockets and just reuse the current protcol
> > handling, except it's not accessible netwide?  That might be simpler. 
> 
> I hadn't figured it out when I was typing in my previous message, but using 
> shared memory forces some build time checking that is missing from our current 
> approach.
> 
> Maybe we should split the discussion into two parts.  One is how to get build 
> time checking.  The second is how to connect ntpq and ntpd.  I'm happy with 
> Unix-domain sockets for the latter.

That would probably be simpler than building another shared-memory interface.

> Note that the current ntpq doesn't have any build time checking and we don't 
> have any version numbers on the ntpq data.  My straw may for cleaning this up 
> is a text file with a line per counter.  It will need 2 preprocessors, one for 
> ntpd/mode 6 and the other for ntpq.  Is there a better way?  (It's slightly 
> more complicated than that since there are several tables, for example one per 
> server, and one per refclock.)

JSON is often used for this sort of thing.  It might vbe overkill here,
but it's worth considering.

> ----------
> 
> [splitting out refclocks]
> 
> > How you handle configuration for separate refclockd and ntpnetd turns out to
> > be a nasty tangle.  Do they both replicate the entire config parser and parse
> > the same config file, ignoroong the bits they don't need?  Or do you split
> > the config and suffer a flag day? 
> 
> I was assuming each refclock would be a separate program.  It wouldn't need a 
> config file, just some command line stuff.

That's a big jump.  Backward config compatibility would go out the window.

> Even if we don't split refclocks out into a separate program, we should run 
> them as a separate thread so we still need an API between a refclock and ntpd.

Yes, I agree with that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>