> As the comment in the code [kern/init_main.c:start_init()] says:
> 
> [snip]
> 
> Note though that having the kernel open /dev/console and using the
> resulting descriptor for stdin,stdout,stderr of /sbin/init isn't exactly
> the right thing to do and won't get you any further ahead than we
> already are.  The right thing to use is cn_tab->cn_dev.

Well, there may be circumstances where a user will want to override the
console device used by the userspace.. e.g. to allow a system to console
on a multiport PCI serial port past the kernel messages.  So allowing
/dev/console to override what the kernel -thinks- the console is is sane.

The question is, if the system is to hand-craft a descriptor, should it
try to hand-craft one from the /dev/console inode first, and fall back
to forming one from the appropriate device numbers in the table?

The reason I liked the idea of creating a new system call is it also allows
the system to gracefully recover should /dev/console later go missing--
e.g. init can still form a console device safely and attach to it.
It also seems like it would be less lines of code and a more generally-
usable facility.

If people decide that is odious, IMO the next best thing is to:
  1) hand-craft a descriptor onto the console device that the kernel thinks
     is appropriate
  2) have init try and open /dev/console, and pass it to setctty()
  3) fall back to the existing 0, 1, and 2 descriptors if all else fails.

I would note this is a bigger total code change, as well.

> The current hack, i.e. check_console() itself, is really just a silly
> way to check if there's a "/dev/console" on the root filesystem, and if
> not print a warning on the device the kernel knows of as the real
> console so that the poor user can stand a chance of seeing it and
> understand why the system grinds to a halt when init fails to find
> /dev/console.

*nods* i understand that..  of course, the kernel could use the information
in the vnode to determine what major, minor to set up fd[0,1,2] on for
init.  That would greatly simplify the init code (as it would not really
need to do much at all to set up the tty) but unforunately would not allow
/dev/console to change.

Another question is whether the behavior for msdos should be generic
behavior..  e.g. there may be other situations where a mfs /dev makes
sense (e.g. NFS-mounted root).

Mike

-- 
Michael P. Lyle