REFCLOCK rises again

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> >> Do you have an example of where we need to change a
> >> driver variable on the fly?
> 
> > No, I'm bothered because I'm (a) not sure we'll never need to do it, and (b)
> > pretty sure what the Dread God Finagle will arrange if I assume we won't. :-)
> 
> I just looked at the code.  There is a table for refclocks.  All are RO.
> 
> While I was there, I searched some more.  There is only one RW in the whole 
> file:
> 
>  * System variable values. The array can be indexed by the variable
>  * index to find the textual name.  Mostly not order-sensitive.
>  */
> static const struct ctl_var sys_var[] = {
>         { 0,                    PADDING, "" },
> #define CS_LEAP                 1
>         { CS_LEAP,              RW|DEF, "leap" },
> 
> I'd be willing to change that to RO and drop the whole idea of writing things 
> via ntpq.

Very tempting.  I'll need to check whether any of the driver-specfic variables
are control knobs.

> That would leave the configure option.  I've never used it.

I think we can justify both removals on security. If Mode 6 is a
read-only channel there can never be any exploits over it.  That's
a significant gain in provable bulletproofness.

You want to reconfure your ntpd?  Bounce it. This won't happen often.

I'm not ready to pull the trigger yet - Achim or Matt or someone else
might come up with a blocking objection - but you're making a strong case.
-- 
		<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.