Hal Murray <halmur...@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>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
