Wonky NTP startup and the incremental-configuration problem

[Hal Murray]

An alternative option would be to implement rereading ntp.conf.

For each line in ntp.conf, there are 3 possibilities.  It's new or the value 
has changed, nothing has changed, or the item was dropped.  The latter is the 
tricky case.

The idea is to save a parsed copy of the old ntp.conf.  As the new file is read in, kick out the old items (if any) as they get replaced.  (Actually, move them to what will be the new saved info.)  Anything left on the old saved-list needs to be set back to the default.

That works for simple things like setting a parameter.  It gets more complicated for things like server/pool/refclock.

It feels like something that's reasonably clean with the appropriate table.

We would need a way to test things.  I wonder if we could do that from a script driving the debugger?


-- 
These are my opinions.  I hate spam.