> I don't think it can be made bakward-compatible with the existing one,
> though. Which means we might as well write a new triver onforming to the
> POSIX shared-memory interface.
I'd be happy to make a new driver and use POSIX. We could call it SHM2, or
SHMP, or ...
The real question is sho
Hal Murray :
> > I'm not clear what you mean by making it read-only. Can you explain?
>
> The current stuff has the sender set a ready bit and the receiver turn it
> off. That only works if you have one receiver. Things like gpsmon can't run
> while it is also being used by ntpd.
>
> You ca
e...@thyrsus.com said:
>> You should probably add cleaning up SHM to your list. I think
>> we want to make the read side read-only. The current approach
>> is polled. Maybe we should move to a socket. ???
> If we move to a socket it's not SHM any more.
I'm being sloppy and using "SHM" as a
>> Is there a better term than alarm? The normal case will be to
>> wait for a packet to arrive with a N second timeout. That's just
>> a timeout on a poll.
> I use 'alarm' because I think of it as what alarm(2) does. I'm not wedded
> to that term.
alarm(2) uses a signal. I think of that as
e...@thyrsus.com said:
>> Could that feature be moved to a packet filter? I think most
>> OSes support some form of kernel level packet filtering. I'm not
>> familiar with any details.
> It could be. That would move control of it out of the ntp.conf file,
> though, which I think would count as
Hal Murray :
>
> Eric said:
> > SINGLESOCK: While messy and somewhat difficult, this is mostly a SMOP
> > (Simple Matter of Programming). There is one potential technical risk,
> > relatively minor I think.
>
> > The reason for iterating over interfaces is that ntpd has the capability to
> > blo
On 05/27/2018 01:56 PM, Hal Murray via devel wrote:
How thread friendly is GO?
Very. Easy concurrency in network software is Go's major raison d'être.
--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A
Man Chooses, a Slave Obeys."/ -- Andrew Ryan
/"Utopia cannot prec
Eric said:
> SINGLESOCK: While messy and somewhat difficult, this is mostly a SMOP
> (Simple Matter of Programming). There is one potential technical risk,
> relatively minor I think.
> The reason for iterating over interfaces is that ntpd has the capability to
> block incoming packets by interf
On 05/27/2018 11:31 AM, Eric S. Raymond via devel wrote:
* GOPREP: Clear the path to moving the codebase to Go. We haven't committed
to doing this yet, but the odds on that happening someday look high enough
that I think it is good to already be factoring it into our planning.
Though it is kn
This note attempts to clarify the next set of architectural challenges
in the NTPsec code. It is particularly intended for Mark Atwood and
Daniel Franke because some of our main goals are tied into supporting NTS.
= OBJECTIVES =
Here are the objectives for the next round of work:
* NTS: Support
I have done a scan over the variables that I have already structified in
recent weeks to see where they get initialized.
Most of the variables I have checked get initialized either at
definition time, or in some sort of init_foo() function. I found three
variables that are never initialized:
11 matches
Mail list logo
