Hal Murray <hmur...@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> _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel