Well, as far as I know, irrespective of what hardware -is- the console,
the console device is always c-0,0.

I think it makes sense for userspace/init to make determinations about
what the console device is..  What I'm looking for is a mechanism so that
1) for embedded systems, an "init" main function can be embedded into the
kernel and the system can exec from one binary image, and gain access to
any devices serviced by device drivers.. and 2) so that the mainline init
can recover in the event /dev/console is lost (but still allowing the
existing init code path to work for people with custom /dev/consoles).

It seems like being able to hand-craft descriptors to devices from user
space would be a useful thing-- for boot-time issues, read-only systems,
etc.

Hand-crafting a vnode/open file descriptor for init is fairly repugnant to
me.. and causes init_main to know -way- too much about the behavior of the
vnode/fd code imo.

Mike

On Fri, Apr 20, 2001 at 02:26:47PM -0400, Greg A. Woods wrote:
> [ On Friday, April 20, 2001 at 02:39:03 (-0700), Michael Lyle wrote: ]
> > Subject: PR 7170 -- init and /dev/console
> >
> > I was thinking about ways to fix this without major kludges (e.g. fixing
> > up a file descriptor in the kernel before init is exec'd).  I have a
> > proposal which might be useful in other operating situations.
> 
> It's really not a kludge at all for the kernel to hand init a file
> descriptor for the console device on stdin/stdout/stderr.  That's the
> way it *should* work, IMO.  The kernel knows what hardware it is using
> as a console and without much trickery it can even know what device
> major/minor numbers it's using so that a stat() would work too.
> 
> > I was wondering what people think of either adding a special fsid_t
> > to fhopen() et al or a new system call to create a fd entry for a given
> > major/minor/type set.
> 
> That won't necessarily solve init's problem unless you assume that
> there's always a pseudo-console device that acts as a loopback
> internally to whatever the real console is (i.e. because init won't know
> any other major/minor numbers).  We do have /dev/console on 0,0 now, but
> I'm not so sure that's a good way to do things on all ports.
> 
> -- 
> 							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>

-- 
Michael P. Lyle