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 <[EMAIL PROTECTED]> //\ I'm a FIG (http://www.fig.org/) Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
