On Sun, Apr 29, 2001 at 06:53:53PM -0400, Greg A. Woods wrote:
> 
> Why?  Only transitions from multiuser mode to single-user mode should
> require `init' to do anything at all to /dev/console.  From single-user
> mode to multiuser there can be nothing to revoke unless the operator
> starts something purposefully, but even then....

I'm just going to let you ponder that.  But I will state flat out that
you've missed something of critical importance.

> Actually why does
> `init' even need /dev/console during multiuser mode?  It should only
> syslog any /etc/ttys-related errors (and *not* to /dev/console!).

It doesn't.  And in fact you'll notice that AFTER /etc/rc runs, it even
closes /dev/console and only opens it again if it's listed in /etc/ttys
and enabled.  However, /etc/rc NEEDS to have /dev/console open -- and
properly revoke(2)ed -- or you can't ^C hung processes during startup.
This is one of the things that always pisses me off about Linux.

> It
> only needs to open /dev/console when it receives a SIGTERM and enters
> state '7'.

You must be living in a fantasy world, since "state '7'" doesn't exist
in this one.

> > Plus, in anything other than a diskless environment, if your /dev is
> > toast you can't upgrade / to r/w to fix it.
> 
> Huh?  That's only true if *all* of your /dev is toast.

Have you EVER seen a case where /dev/console was missing but disk
devices were present?  I have no doubt that you'll say `yes', but *I*
haven't, ever, under any circumstance.  The only case in which it's
even really plausible is file system corruption.

> However if MAKEDEV were in /sbin, and if you have some way to mount some
> other writable filesystem over /dev and thus create a working /dev (at
> least for the root device), AND if one were permitted to make a second
> mount of a partition that's currently only mounted read-only(*), then
> you could mount the root filesystem (on which the toasted /dev lives) as
> read-write on /mnt and fix it that way.  You can then simply unmount the
> root FS from /mnt and then upgrade it to multi-user mode.

In other words, if we did a bunch of half-assed hacks to deal with a
case that never happens in practice.  No thanks.

If we want to solve the `/dev problem' for good, then we need a devfs.
Doing a bunch of little hacks that give you a totally obscure recovery
path is a suboptimal non-solution.

> (*) I don't see any reason to prevent a read/write mount of any
> read-only mounted filesystem as is the case today, particularly not in
> single-user mode.  The buffer cache should keep the two views of the FS
> in sync.

Bzzzt.  You forget the inode cache and the name cache.