Subject: Re: PR 7170 -- init and /dev/console
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Charles M. Hannum <email@example.com>
Date: 04/29/2001 20:52:54
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.
> 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.