Fwd: Future directions
jamesb.fe80 at gmail.com
Mon Sep 16 23:08:27 UTC 2019
---------- Forwarded message ---------
From: James Browning <jamesb.fe80 at gmail.com>
Date: Mon, Sep 16, 2019 at 4:07 PM
Subject: Re: Future directions
To: Mark Atwood <mark.atwood at ntpsec.org>
On Mon, Sep 16, 2019 at 3:24 PM 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"
> (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?
I vaguely (mis)remember reading something saying that was a problem.
My list contains.
- a multicast DNS broadcaster for NTS.
- additions to the DNS code to allow non-A/AAAA pools. (cname/srv probably)
- Additions to the DNS code to allow for mdns monitoring.
- Do something else with the Python module builder.
- less awful asccidoctor support. use waf unit test infrastructure.
- replace mode6 with a tcp service. (it was only IIRC in v2-3 RFCs)
- - or work on the auth code for ntpq a bit.
I've worked a bit on most of those.
Given the increase in threading would it be possible to shove smb auth into
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel