[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