ntpq, refclocks

[Hal Murray]

[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.

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.)

----------

[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.

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.


-- 
These are my opinions.  I hate spam.