e...@thyrsus.com said: > The two most obvious pain points here are the fudgetime variables. Some > refclocks set their own custom clock variables, as well; the generic driver > in particular, I think one other as well.
The fudgetime variables can remain in ntpd. If the problem is the driver setting variables at initialization time, that should be easy to fix. It's slightly more complicated to change things on the fly. I'm thinking of things like up/down as the cable gets unplugged or the signal fades out due to rain. Do you have an example of where we need to change a driver variable on the fly? ------- >> We need to be able to run gpsmon while it is feeding data to ntpd. Replace >> gps with your favorite refclock. > You'll have to say more, I can't unpack this. I want to be able to run something like gpsmon while the driver is connected to ntpd. If we use SHM, I know how to make the client side read only so we can have any number of clients. I don't know how to do something similar with pipes. I'm willing to do something like a TCP listener . Maybe an internal SHM interface and a thread per pipe. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
