BIG NOTE:
SVR4's may differ.  My experience is on Amiga Unix, which was an excellent
system.

>I'm not sure.  What exactly is being proposed here?  As far as I can
>see, SysV-style inits differ in three ways from the BSD kind:

>- SysV has an /etc/inittab driving file; BSD init has no driving file
>   for startup and shutdown (it does have /etc/ttys for tty lines).

inittab is only a partial driving file.  inittab covers which
programs should restart periodically, and in SVR4, a lot of this functionality
goes away.  (For instance, there were not gettys in inittab.  There was a
program called ttymon, one instance of which would drive, say, up to 1024
ports, or, in my case, all 7 serial ports, or all 10 consoles.  And one
sat around waiting for telnets and rlogins.)

>- SysV has run-levels (which really do nothing but select fragments of
>   /etc/inittab to be executed); BSD init has, effectively, three
>   run-levels wired in: down, not running stuff from /etc/ttys
>   ("single-user"), and running stuff from /etc/ttys ("multi-user").

This does not correspond to the SysV I used.  It had
/etc/rc.d
which contained many scripts, and
/etc/rc1.d, /etc/rc2.d, etc
which contained the links for a given run level.  For instance, rc2.d might
have
K22nfs -> /etc/rc.d/nfs
S10ttymon -> /etc/rc.d/ttymon
(made up, but about right)
meaning that you would first do /etc/rc.d/ttymon with the argument "start",
and then /etc/rc.d/nfs with the argument "stop".

The inittab stuff was pretty limited; the primary thing it had was
(and this is unclean, considering how all other lines are read)
is:2:initdefault
which meant that 2 was the default runlevel.

You could add programs to inittab, but it was no longer really
the primary focus of the init levels.

>- SysV init knows nothing of startup or shutdown scripts, letting those
>   be handled by inittab entries; BSD perforce teaches init about
>   /etc/rc for startup.

The former is not quite as true anymore.  I'd like to see init handle
all "state changes" by calling a script which does the actual
state change work.  I don't mind the inittab way of doing ports, but I
don't mind ttys either.  The SVR4 ttymon had some major wins, but a couple of
gigantic losses (mostly just that it was slow to change.)

>Thinking about this, and taking the philosophy of making tools as small
>as possible, each doing as little as possible, I think the right way to
>proceed would be to divorce running gettys from administering startup
>and shutdown.  One could perhaps make a case for splitting reaping
>orphaned processes off from the others, but I see no reason one of the
>above two couldn't handle that; they both need to handle process
>waiting and reaping anyway.

>I would then have init, the traditional process 1, know nothing of
>run-levels; all it should know is "up" and "down".  Single-user versus
>multi-user should be handled by shell scripts; most args to init should
>be passed to the startup shell script, and could drive its decision to
>run a sh on the console versus running the getty spawner, the one
>that's driven by /etc/ttys.  Indeed, one could probably do this with a
>current NetBSD system by replacing /sbin/init with a shell script.  (I
>know this - replacing init with a shell script - works under SunOS 3.5;
>I see no reason it wouldn't work under NetBSD, but I haven't tried it.)

This is, so far as I can tell, the direction SVR4 seemed to be moving in, but
a good one nonetheless.  init should reap.  It should know to start
/etc/rc.  And it should stay out of the way, mostly.  Arguably, it should
restart /etc/rc with different args, or otherwise handle state changes, but
that's up for grabs.

>Well, I've already ranted about commercial apps in the past, so I'll
>confine myself to noting that I don't trust them to restrict themselves
>to their own files _regardless_ of what style of administration one
>does.

Sometimes I almost wish we had VMS like privs, so I could mark something
unwriteable by normal sysadmins, but let them modify other stuff.  Oh, well.
(I say "VMS like" meaning vast, complicated, and designed to control power in
tiny bits, not because I have any clue how it works.)

-s