Subject: Re: PR 7170 -- init and /dev/console
To: None <tech-kern@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 04/21/2001 03:54:57
[ On Friday, April 20, 2001 at 17:15:23 (-0700), Michael Lyle wrote: ]
> Subject: Re: PR 7170 -- init and /dev/console
>
> To do this.. either additional facility needs to be put into the vnode/fd
> code to hand-craft file descriptors or init-main.c has to understand way
> too much about the inner workings of file descriptors in my opinion.

As the comment in the code [kern/init_main.c:start_init()] says:

        /*
         * This is not the right way to do this.  We really should
         * hand-craft a descriptor onto /dev/console to hand to init,
         * but that's a _lot_ more work, and the benefit from this easy
         * hack makes up for the "good is the enemy of the best" effect.
         */
        check_console(p);

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.

I don't think hand crafting a descriptor should be all that much work
either (though I've not actually tried implementing it, yet :-).
There's already some crafting of file descriptors for process zero.

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.

It's also pretty silly that init calls warn() before login_tty() can
ever be called and thus before stderr is open!  ;-)  [even though it's
pretty much impossible for the errors being reported from ever occuring
from process 1]

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>