[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: runlevels


thanks for the clarifications. I now see that I forgot about the additional
Hurd power.

But please understand that I am just trying to port existing working
infrastructure from Debian GNU/Linux to the Hurd. The new Hurd way will
require substantial changes to the packages and the Debian policy document.

(and to the Hurd source, too, that means implementing new servers etc).

On Mon, Feb 22, 1999 at 04:56:35PM -0600, Gordon Matzigkeit wrote:
> 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.

Ok. It will need some time until thiese features are fully exploitable in
the existing packages.
> 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.

I see now that the use of init scripts will therefore be less on the Hurd,
and now I understand why Thomas considers sysvinit as too complex.
> 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.

Okay. I see now. Still, what about higher level services like apache?
> 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.


> 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.

We will have a sysvinit package anyway.
> 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.

If I understood everything correctly, and if the sysvinit program is
informed on each runlevel change, this solution is fine with me. How hard is
it to implement?


`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09

Reply to: