[ntp:hackers] Privacy: refclock_nmea is now munging lat/long

Hal Murray hmurray at megapathdsl.net
Sun Apr 26 08:40:02 UTC 2009

> I'd rather see this be a runtime config thing.

My vote would be to comment out the current munging, get the release out, and 
then work on a clean fix.

What is your current list of things holding up the release?


I'm not up to speed on the new config file parser.  In the old days, the only 
driver specific parameters you could feed to a driver was the mode option.  
That was only 4 bits.  4 is a small number.  We need more, preferably more 
flexibility as well as more bits.

Is there a simple way to pass driver specific config info to a driver?  I 
guess I'm happy if we keep all the parsing in the parser and have the drivers 
only grab what they want, but I'd rather see an error message than have a 
parameter silently ignored.

Specifying the baud rate (and maybe parity) would be a good test case.  (It's 
also a good example of why I'd like an error message if a driver doesn't 
understand a parameter.)

Note that there is an interesting complication in this area.  The file is 
opened right after the server line is parsed.  The system doesn't wait to see 
if you fudge-d something.  So the baud rate parameter has to be part of the 
server line rather than a separate line.

Has anybody thought about how to do this cleanly?  Is it time to add a config 
routine to the driver dispatch procedures?

These are my opinions, not necessarily my employer's.  I hate spam.

More information about the hackers mailing list