In article <op.ydtha6t65znmjo@fennec>, Morgan ``indrora'' Gangwere <morgan.gangw...@gmail.com> 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
