Hal Murray <hmur...@megapathdsl.net>:
>
> e...@thyrsus.com said:
> >> My strawman for REFCLOCKD is something like the touring test.
> >> You can't tell the difference by poking around with ntpq. (Maybe
> >> you don't get to poke too deep.)
>
> > It'd need its own UDP port.
>
> I don't understand. All I was trying to say is that splitting out the
> refclock drivers to another process shouldn't make any difference that is
> easily visible.
Maybe. The devil is in the details.
I expect some issues around Mode 6. We'd still need to exchange
control packets with it to query and set clock variables.
> > I like Unix named pipes for this kind of scenario. They're very
> > straightforward, no buffering or hidden magic, no interaction with the
> > network code (thus no possibility of remote exploits), and an ironclad
> > atomicity if you keep your writes 512 bytes or below.
>
> Sounds good. I suspect the hard part will be coordinating
> start/stop/crash/recovery.
>
> How do we get 2 processes to read the same data?
We don't. Why do you expect to need this?
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
