New ntpq peers chops refclocks to 6 characters

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>: 
> How does your new stuff handle multiple instances of a refclock type?

So far it's only cosmetically different from the old syntax.  The
refclock directive has the combined options of the server and fudge
directives - in fact they're parsed by the same code and the same
subproductions in the grammar.  Only the top-level grammar production
for the refcloc directive (and a small amount of glue logic) are different.

The good news is that this means the refclock directive can
automatically do anything the old server+fudge directives could.  The
bad news is there are some resulting ordering constraints - all the
fudge options have to come after all the server options.  I plan to
fix this.  It was the price for an implementation that could be spun
up quickly.

> For a test case, I suggest a USB driver in addition to a HAT.  Try both 
> NMEA/PPS as well as both SHM and various combinations.

I'll see how elaborare I can get.

> The JSON driver uses the high bit of the unit to enable/disable the PPS.

Yes, I've noticed,  It's ugly. Seems like that ought to be an option bit
of its own.

> The NMEA and HP drivers use the mode/ttl slot to select the baud rate.  There 
> are probably others that do something similar.   As long as you are changing 
> things, you might as well clean up how the baud rate gets passed in.  It 
> needs that before it opens the /dev/tty.  The old fudge stuff is too late.  
> (Or was at one point.)

Hal, that is such an excellent idea that it just went to the top of my
short-term to-do list.  I might have to sleep before I do it, though.

So you have a better idea of the process and what the constraints are:

What I'm going to do is add "bps" or "baud" as a server option with a
numeric value, a peer to "mode".  The refclock directive uses those
grammar productions - and hands off, in part, to the same function that
processes the server options.

At the time "mode" is processed by that function, I'll also look at
the bps value.  If it's nonzero (because specified) I'll ignore the
mode baudrate bits and use that value instead.  Presto, not only does
the refclock directive get a sane baudrate option, the server
directive does too.

That change is going to knock a whole *lot* of ugliness out of the
driver manual pages.

More suggestions like this, please.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>