Re: inetd improvements [gsoc16]

["Morgan ``indrora'' Gangwere" <morgan.gangwere%gmail.com@localhost>]

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.



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

> > On a process related note, I have a few questions:
> >
> >  * Where can I find a style guide? (Obviously, I want^H^H^H^H need to  
> > keep
> > my contributions in KNF)
>
> http://nxr.netbsd.org/xref/src/share/misc/style

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

> >  * I'm not totally familiar with working outside pkgsrc -- Is there a
> > wikipage on building the system bits of netbsd?
>
> You can check out the source tree and then run a build using build.sh.
> This works on non-netbsd systems too. There is a BUILDING file in the
> top level directory

Neat, I've got initd building and starting as it should.

> >  * What sort of work has been done on inetd in the past?
>
> You mean by other OS's? The other thing to look at is launchd which
> is a superset of the inetd functionality (supporting dependencies etc.)
> Perhaps even replacing inetd with launchd.

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?

> >  * What sort of plan does the NetBSD project have for the future?
>
> For inetd or in general? See above.

ack.

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.

> > I've noticed that a lot of tools in usr/sbin are kept in big, monolithic
> > slabs. I understand this is because of historical reasons, but is there
> > any plan to move ahead? Would inetd be a good place to start splitting  
> > up
> > these hulking 2k sloc behemoths?
>
> Give some examples of which you would like to split and into what...

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.



--
Morgan Gangwere      <morgan.gangwere%gmail.com@localhost>
www: zaibatsutel.net twitter; @indrora (also GH)