Re: runlevels

[Gordon Matzigkeit <gord@trick.fig.org>]

I'll redefine Thomas's terms for a second, so that his position is
clearer (at least, I'll represent it in the way I understand it):

His ``single-user mode'' is something for which there is no parallel
on Debian system.  I would rather call this ``the rescue shell'',
since that's really what it is.

Thomas's ``multiuser mode'' would be better dubbed ``automatic
startup''.

Debian's runlevels are merely different types of automatic startup.
Linux has no such thing as passive translators, but the Hurd can use
them to eliminate nearly every aspect of system startup, by deferring
initialization until it is actually needed.

Marcus's example of foreign keyboards is a good one.  I imagine under
Linux, it is implemented by a program that sends a bunch of ioctls to
the kernel shortly after startup.  On the Hurd, it would make sense to
be able to specify keyboard settings as arguments to /hurd/term, or a
configuration file that /hurd/term can read, then just change the
/dev/console (or other console) translator.

Thomas's plan, to the best of my knowledge, is to deal with each of
these issues as they come up, and implement them in an appropriate
server.

As another example, notice that the rescue shell has access to the
network, even though no network config script has been run.  If you
try executing telnet, it'll tickle /servers/socket/2, and that will
activate /hurd/pfinet with the correct parameters.  But, if you don't
run telnet, then pfinet won't start.

It all comes down to the fact that a working Hurd configuration should
only need /boot/servers.boot, and a bunch of passive translators.
Everything more active than that (such as starting inetd, or the
gettys) can be done quite easily from /libexec/rc.

That approach makes rescue mode both useful, minimal, and robust.

So, what do we do about runlevels?  Well, I would suggest that they
are a specialization of the Hurd's automatic boot mode, and should be
treated as such.

Let's have a program called `sysvinit', which can be called from
/libexec/rc, or symlinked to it.  That program will read /etc/inittab,
and do all the magic of emulating a Debian system.  The `telinit'
program would contact sysvinit via RPC to change the ``runlevel''.
When it exits, it will kill off all its children.

Then, we only have a few outstanding issues:

1) It is possible to boot into the rescue shell without a password.  I
   disagree with the idea of patching Hurd init to require a password
   to get into rescue mode.  If you want protection, then let's change
   GRUB so that it refuses to boot Mach in anything but automatic
   mode, unless you enter a password.

2) `shutdown' with no args is supposed to drop into runlevel 1 (still
   in automatic startup), but on the Hurd, it drops to the rescue
   shell.  `halt' and `reboot' have similar problems.  For Debian,
   let's split the Hurd's shutdown into a separate binary package, and
   bundle sysvinit and telinit with a shutdown that understands
   runlevels, and takes a special flag (such as `--rescue') to drop
   to the rescue shell.

3) `sysvinit' needs to make the Hurd's init wait for it when shutting
   down, or else the stop scripts might be interrupted.  This should
   be a relatively easy thing to implement.

Does this make sense?  I think it should be clear that we can package
a sysvinit for the Hurd without needing to make any changes to the
existing infrastructure.

A separate sysvinit package will come in handy, and there's no
compelling reason to put all that functionality into the Hurd init
program anyway.  Let's leave the Hurd sources blissfully unaware of
sysv, please. ;)

Personally, I'm looking forward to Thomas's new approach to runlevels,
but an independent sysvinit package will provide sysv compatibility
for as long as we need it.

-- 
 Gordon Matzigkeit <gord@fig.org>  //\ I'm a FIG (http://www.fig.org/)
Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)