Achim Gratz via devel <devel@ntpsec.org>:
> > The biggest problem with any attempt to break up ntpd into multiple
> > separate programs is that it would almost necessarily force changes in
> > the way NTP configuration works that would be (a) user-visible, and
> > (b) not backward compatible. The only ways around having such a
> > configuration break I was able to think up were so complicated and
> > ugly that they seemed like non-starters in themselves.
>
> Again, if you DJB the whole thing, then interpreting the configuration
> is just another low-privilege process that leaves some data around for
> the other processes to pick up.
Sure, I thought of that. But if I were to do that I would (as the old hacker
joke about regexps goes) have *two* problems. That is, two layers of
configuration interpretation, both attracting defects. See "complicated
and ugly", above.
> Whether ntpq communicates with a single process or several or maybe even
> some sort of relay that gathers and scatters among multiple processes
> doesn't really need to change the way it's going to present the result
> to the user.
No, but the extra code to manage N different control/status channels
to N different pieces is a complexity cost that I think could easily
balloon on us.
> What you may be missing is that the whole "let's look at a bunch of
> system on the internet and figure out what time it most likely is on
> their side", i.e. the whole NTP client part (sans actually changing the
> sytem time) can be treated like just another refclock. You'd end up
> with an architecture in which refclocks of any sort collect statistics
> about time that the component that adjusts the system time is then using
> without any need to care about how they've been obtained.
Again, of course I thought of this. If I ever actually do break out
the refclocks, the interface to them will look like reclockd is a
network peer.
> > I've gone through several rounds of looking at the repartitioning
> > problem, mentally trying different ways to carve ntpd apart, and every
> > time around I've reached the same conclusion: it's too complicated to
> > be worthwhile.
>
> Well, even if you don't actually split it up into processes or threads
> it is still a good idea to compartmentalize the separate concerns.
Which is why one of the long-term cleanup projects is to gather the
large number of globals that now exist into a small, well-defined set
of semantically coherent context structures.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
