Hal Murray via devel writes:
> I'd like to move the current kernel mode PLL to user space. I think modern
> CPUs are fast enough for that to make sense. I haven't done any
> experimentation.
That doesn't buy you what you seem to think it does.
This in-kernel PLL (at least on Linux) benefits f
Hal Murray :
> Maybe ntpd should turn into a mega program that parses the config file and
> runs a bunch of other programs and/or threads.
That's an extremely natural way to partition in Go. Much, *much* easier than
trying to pull off the equivalent in C would be.
--
http://www.
>> I was assuming each refclock would be a separate program. It
>> wouldn't need a config file, just some command line stuff.
> That's a big jump. Backward config compatibility would go out the window.
I'm not sure about that. ntpd could start the program using info from the
server and fud
Hal Murray :
> [context is ntpq via shared memory]
>
> > Any reason not to use Unix-domain sockets and just reuse the current protcol
> > handling, except it's not accessible netwide? That might be simpler.
>
> I hadn't figured it out when I was typing in my previous message, but using
> share
[context is ntpq via shared memory]
> Any reason not to use Unix-domain sockets and just reuse the current protcol
> handling, except it's not accessible netwide? That might be simpler.
I hadn't figured it out when I was typing in my previous message, but using
shared memory forces some build
Hal Murray via devel :
>
> Does anybody have any good ideas on a modern way to handle ntpq/mode 6?
>
> Background...
>
> We could split the server side out into a separate process. That leaves a
> very tiny attack surface from the network. I think I could do that now
> except
> for mode 6.
Does anybody have any good ideas on a modern way to handle ntpq/mode 6?
Background...
We could split the server side out into a separate process. That leaves a
very tiny attack surface from the network. I think I could do that now except
for mode 6.
Does anybody have any good ideas on how
