On Mon, Nov 17, 2025 at 10:26:24AM +0100, Martijn van Duren wrote:
> On 11/17/25 03:25, Mike Larkin wrote:
> > On Fri, Nov 14, 2025 at 10:07:46AM +0100, Martijn van Duren wrote:
> >> Hello all,
> >>
> >> A long time ago I removed the control bits from snmpd's proc.c, because
> >> snmpd lost any use for snmpctl. Revisiting proc.c made me realize that
> >> control setup functionality doesn't need to be in proc.c, and only
> >> forces us into creating the process, regardless of being needed.
> >>
> >> Since I have the impression that vmd is currently the most actively
> >> maintained proc.c consumer I started here, but it should probably go
> >> just as well for the other consumers, which I'll visit if people agree
> >> with me here.
> >>
> >> Diff below removes all the control bits from proc.[ch] and places them
> >> in their equivalent places inside control.c and struct vmd. Since vmd
> >> doesn't allow for multiple control sockets I've only took over the
> >> main, and dropped the TAILQ bits.
> >>
> >> Thoughts? OK?
> >>
> >
> > dv@ should decide here. not sure I grok this but at first read it seems like
> > shuffling deck chairs? what benefit does this gain?
>
> It is shuffling deck chairs. The short: maintainability of proc.c in
> general.
> The PROC_CONTROL bits add special casing and complexity to an already
> complex file without any additional value. Removing this special
> casing makes proc.c more readable, and when also applied to the other 3
> proc.c daemons (iked, httpd, relayd) makes them that little bit more in
> line with eachother.>
> >> martijn@
>

dv@ should make the call here.