Subject: Re: Console Magic redux
To: None <firstname.lastname@example.org, email@example.com>
From: Chris Torek <torek@BSDI.COM>
Date: 11/27/2000 12:18:35
>Finally, there is the case with mismatched input and output. We
>actually support this configuration so you can have two separate
>drivers as the console, one for input and one for output.
Well, with "top half directed" consoles, that just means two internal
>>(I personally still think the "right" way to handle console-ness
>>is to autoconfig as usual, then have the top-level kernel open
>>the appropriate I/O stream -- which may even be a network connection
>>-- and hold it open forever as "the console". But this is another
>How does the top-level kernel determine which I/O stream should be
That part is difficult. :-)
As far as I can tell, that has to be done MD-ly. In some (many?)
cases each driver might declare itself as "console-able" as it
configures. It would not yet *be* "the" console, just capable of
becoming one. Eventually some higher-level code, which has a better
"big picture", makes the decision. (And the rest of them become
inconsolable ... no, sorry, I just could not resist the pun :-) )
Note that a network stream might break, so all of this sort of implies
that "console-ness" can be revoked later, and moved elsewhere.
MD code might need to start out by finding some sort of console
"by magic" (on sparc, "by using the PROM"; on i386, maybe assuming
keyboard and VGA display; etc.) and using that until the kernel
takes over. This means there would be a "provisional, boot-time"
console (or pair of separate consoles, for split keyboard/screen).
Note also that this is something like the "virtual console"
(TIOCCONS ioctl), only generalized.