---------- Forwarded message --------- From: James Browning <jamesb.f...@gmail.com> Date: Mon, Sep 16, 2019 at 4:07 PM Subject: Re: Future directions To: Mark Atwood <mark.atw...@ntpsec.org>
On Mon, Sep 16, 2019 at 3:24 PM Mark Atwood via devel <devel@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?
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
