[ On Thu, June 27, 1996 at 14:24:10 (-0400), Chris G. Demetriou wrote: ]
> Subject: Re: NetBSD 1.2(beta) mounting msdos long file names. 
>
> > how does this get around the fact that /dev/console is missing
> > and that init will fail, or whatever it is that happens ?
> 
> If you want your BONUS! evil points, you can get them by hacking init
> to do the right thing early on...  8-)

*Now* I remember the "solution" I had discovered to this problem many
years ago when I first encountered a "unix" with a broken init that I
was contemplating replacing:

On most (many? all?) platforms the kernel has already discovered what
the physical console is, and has probably already written messages to
it.  Now on some systems (is NetBSD this way generally now too?) the
device "pointed-to/referenced-by" the /dev/console special file is
internally re-directed/connected to the physical console hardware.  As I
understand in at least some NetBSD ports this is done by simply pointing
the virtual console device at the driver for the hardware which is
currently configured to be the "real" console.

So, my idea/question is why can't the kernel craft some open file
descriptors for the console device and connect them to the init process'
STDIN/STDOUT/STDERR?  Of course it can't associate these file
descriptors with a real vnode, but perhaps this isn't necessary, or
maybe it could be faked with a miniature virtual filesystem?

I think this would allow init to operate without having to open the
/dev/console file, and thus make it possible to start up a system with a
mere minimum of a kernel and /sbin/init + /sbin/sh.

Perhaps it's easier to just have init mknod("/dev/console",
S_IFCHR|0600, 0); (or whatever) if the open fails....

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>