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