>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
opens.

>>(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
>>matter entirely...)

>How does the top-level kernel determine which I/O stream should be
>the console?

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.

Chris