ntpd: program structure

[Eric S. Raymond]

Achim Gratz via devel <devel at 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.