tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: inetd improvements [gsoc16]

On Wed, 02 Mar 2016 08:48:32 -0700, Christos Zoulas <christos@> wrote:

In article <op.ydn26ms65znmjo@>,
Morgan ``indrora'' Gangwere <morgan.gangwere@> wrote:

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)

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


Our closest sibling has made some changes to inetd to make it a "little more" configurable [ ]

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      <>
www: twitter; @indrora (also GH)

Home | Main Index | Thread Index | Old Index