Future directions

[Eric S. Raymond]

Mark Atwood via devel <devel at ntpsec.org>:
> On Mon, Sep 16, 2019, at 14:09, Hal Murray via devel wrote:
> > I think we should put the current stuff on the back burner and make a new SHM 
> > interface where the clients are read only.
> > 
> > Is shmget/shmat the right API to use?  I remember discussions of there being a 
> > wrong API but don't remember any details.
> 
> I always liked the idea of moving to a shm or a local socket "clockd" interface. 
> 
>  (Under the hood, a UNIX domain socket or a 127/8 localhost socket is nothing more than merely a shm segment and two semiphore locks.)
> 
> A clockd interface was, in fact, part of the original plan.  Maybe make it the plan again?

There was a thing called clockd in my original technical plan. The
concept was to carve ntpd in half, separating the network engine from
the local clock management.  The local clock manager would look like
just another peer.  The expected benefit was to reduce the bulk and
attack service of the network part.

Looked lke a really appealing idea when there were 45 drivers.  Bacame
less so as the bulk of the driver code dropped precipitously, because
the (essentially) fixed complexity overhead of a new wrapper for the
drivers got larger in proportion as the expected gain was decreasing.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>