Fwd: Future directions

[James Browning]

---------- 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>
wrote:

> 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?
>

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
a thread?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190916/84f86e28/attachment-0001.htm>