>Drivers may think they are the console but be very wrong.
	>On some machines, like SPARC, one device can register as the console
	>only to find another device has replaced it later.

	Erm, are consoles dynamic, then, or are these devices just
	mistaken to begin with?

Neither, really.

The console can be one of:

		A serial port driver

		A keyboard line discipline layered on top of a serial
		port driver

		A keyboard driver

		The PROM console driver.

The PROM console driver attaches only if no other device has claimed
the console.

A serial driver on the console input path will think it's the console
even if it is attached to a keyboard.  If it is attached to a keyboard
then the keyboard driver really should be the console, but it requires
the serial driver's I/O routines to operate.

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.

	(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?

Eduardo