Re: inetd improvements [gsoc16]

[christos%astron.com@localhost (Christos Zoulas)]

In article <op.ydtha6t65znmjo@fennec>,
Morgan ``indrora'' Gangwere <morgan.gangwere%gmail.com@localhost> wrote:
>On Wed, 02 Mar 2016 08:48:32 -0700, Christos Zoulas <christos@> wrote:
>
>> In article <op.ydn26ms65znmjo@>,
>> Morgan ``indrora'' Gangwere <morgan.gangwere@> wrote:
>>> [trimmed]
>>
>> Yes, I think that a per-service file with better syntax is probably the  
>> way to go. I think that it is not worth enhancing more the existing  
>> syntax.
>
>I have some reservations either way. It's worth exploring in the proposal  
>the pros/cons of the basic approaches I see:
>
>* Abandon the old format and make people move. (maybe include a tool to  
>parse the old format and spit out new-world config files)
>* Shoehorn configurability into inetd (either by keeping two config  
>languages or by extending the current language)
>* Split inetd into inetd-legacy and inetd-ng, giving the choice of  
>abandonment or new-world config files. inetd-legacy is put on life-support  
>and inetd-ng becomes optional.


That would be simple, it can be done with a shell script or awk; if you
see inetd.conf migrate it to /etc/inetd/<service>. But it is also simple
to leave the current parser alone, and accept the new syntax only in the
per-service files. Let's start with that, and see where it takes us.

>> If you need new features, use the new way. Perhaps have a /etc/inetd  
>> directory for the system services and a /var/inetd for the user  
>> requested ones.
>
>Is there a standard for the layout on NetBSD systems of where such things  
>should go?

I am not sure; I know what goes where is documented somewhere but it is not
very details.

>Awesome, thanks.
>
>Another process related note: If I have to pull in someone else's code  
>(i.e. parser) is there a specific license I must adhere to? (Alternately,  
>I know "no GPL code in the kernel" but how does this apply to userland?  
>What parsers are available already to userland utilities? Is there a good  
>list of what I can reuse easily?)

No GPL code in userland either, specially if the existing program does
not have GPL.

>I saw that there's a project to try and port launchd. After boiling my  
>toes in the debate about systemd, which made genuine improvements on the  
>Linux init system from SysV, I'm curious what the debate has been about  
>bringing Apple's additions to the BSD ecosystem to the NetBSD world.
>
>The polarizing issue here is: Do we break things, or do we continue on? If  
>we change the inetd configuration and someone does a transition from  
>NetBSD-7 to NetBSD-8 let's call it, what's going to happen to them? Should  
>a tool be included to migrate from inetd-old to inetd-new?

Well, launchd does not have to replace init (at least init-ially :0) so it
is less controvercial. We can provide automatic migration scripts, but it
is nice to be compatible. This way you can go back and forth.

>Our closest sibling has made some changes to inetd to make it a "little  
>more" configurable [  
>https://www.freebsd.org/doc/en/books/handbook/network-inetd.html ]
>
>Changing the "wait/nowait" field and making it a more generic "options"  
>field with k=v pairs (vis-a-vis mounttab) has its pros (zero loss of  
>backwards compat) which make it comfortable to implement but the cons  
>(lack of explicit directory-based configuration, we're limping along a  
>format that hasn't changed since I before I was born) don't seem to align  
>with the goals of the NetBSD project.
>
>What I don't want to see (ultimately) is breaking trust.
>
>Again, I'll explore these with pros/cons in my proposal.

Sounds good.

>inetd is currently { inetd.c ipsec.c ipsec.h pathnames.h }
>
>inetd could easily be broken up into { inetd.c inetd.h buitins.h  
>builtins.c children.c children.h config.c config.h ipsec.c ipsec.h  
>pathnames.h } - each compilation unit focuses on something specific  
>(builtins, children processes, configuration) and makes it miles more  
>readable. My editor multibuffs -- but make doesn't; one giant compilation  
>unit made sense when we were building on big mainframes that had one core  
>and everyone took turns. My laptop shouldn't have to cry because it has to  
>wait for cc to churn.

Sure that sounds a lot nicer.

christos