Refclocks and formatting
Eric S. Raymond
esr at thyrsus.com
Sun Apr 23 18:17:00 UTC 2017
Hal Murray <hmurray at megapathdsl.net>:
> There is another potential worm in this can. I don't think if it applies to
> this case, but it's worth keeping in mind.
> Some of the flags that get decoded come from the kernel sources rather than
> NTP sources. They are generally the same across OSes and kernel versions,
> but I don't know how to verify that. I think the clean solution would be to
> decode them on the server. [Or copy the versions from one kernel to our
> sources and have the build step crash if they are defined in the kernel and
You are right to raise this issue. Either fix would be messy though.
Mode 6 should really not be shipping those flag bits in hex at all; it
should decode them into a list of mode strings. That would be the
*right* fix, but of course it would break mode 6 backward compatibility.
I'm tempted to do it anyway. I'm normally extremely wary of doing things
that might break sysadmin scripts, but this is a rather improbable case -
somebody would have to be decoding those bits with a thing that isn't
ntpq or ntpmon itself to be affected.
We could keep the old behavior under ENABLE_CLASSIC_MODE. Hm. Hal,
what do you you think our actual risk exposure is here?
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.
More information about the devel