inetd improvements [gsoc16]

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

targeted at christos mostly.

I saw the GSOC posting that inetd needs some love.

About me: I'm a student at the University of New Mexico. I'm not afraid to  
dig my hands into a codebase and fix things, add things or otherwise get  
work done. My projects have primarily been "Take this existing thing and  
fix this annoyance with it". I've gotten my hands into a variety of BSDs  
and *nixes (I even experimented with NetBSD back when I was using a Zaurus  
for a while). I maintain a tiny linux container to get used to small  
environments at < zaibatsutel.net >

I have a (vaguely) self-serving reason to work on inetd: I use it. In  
several simple systems, I use NetBSD's inetd to serve simple shell-script  
based services.

I think the per-service configuration might be the first thing to handle,  
however. At the moment, the "best" way to implement adding configuration  
for rate-limiting and friends would be to hijack part of inetd.conf  
(probably adding options to proto, making config syntax something like  
"tcp4,limit=10,20" for 10 invocations in 20 seconds, and potentially to  
progname, meaning ssh,prefork=2 would keep 2 children waiting). On one  
hand, it's historically consistent: adding more options is a time-honored  
tradition. On the other hand, it's starting to show its age. Potentially  
making /etc/inetd/(service).conf or /etc/inetd.rc hold things is a better  
idea? I'd like to see what old UNIX admins with graying beards have to say.

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)
 * I'm not totally familiar with working outside pkgsrc -- Is there a  
wikipage on building the system bits of netbsd?
 * What sort of work has been done on inetd in the past?
 * What sort of plan does the NetBSD project have for the future?

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?


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