Re: [PATCH] CON_BOOT

[Matthew Wilcox <matthew@wil.cx>]

On Tue, Mar 15, 2005 at 02:37:11PM -0800, Andrew Morton wrote:
> Matthew Wilcox <matthew@wil.cx> wrote:
> >
> > +	if (console_drivers && (console_drivers->flags & CON_BOOT)) {
> > +		unregister_console(console_drivers);
> > +		console->flags &= ~CON_PRINTBUFFER;
> > +	}
> > +
> 
> Should we support more than a single CON_BOOT-labelled driver?

I want to say yes.  But there's a can o' worms lurking under the surface.
Our goal is to get output from as early as possible, then have the real
console driver take over from the (boot|early) console in a completely
transparent way.

With just one console, this is straightforward.  The BOOT console gets
unregistered, the replacement console gets its PRINTBUFFER flag cleared,
everybody's happy.

With two (or more) consoles, it's a bit more tricky.  If there's only one
BOOT console and the corresponding real console gets registered first,
its PRINTBUFFER flag is cleared and it continues, then the second console
kicks in and doesn't get its PRINTBUFFER flag cleared.  Everything looks
pretty, we're all happy.  If the wrong console gets registered first,
we miss the start of the log on it, and the BOOT console gets the start
of the log printed twice.

If we allow two BOOT consoles, we guarantee that one of the consoles
will get double-printing, but neither will miss the start of the log.

To handle this properly, we'd have to be able to see which BOOT console
corresponds to the real console and deregister it.  I think it's doable
if we do something like:

 - Add an int (*takeover)(struct console *); to struct console
 - Replace the hunk above with:

	for (existing = console_drivers; existing; existing = existing->next) {
		if (existing->takeover && existing->takeover(console)) {
			unregister_console(existing);
			console->flags &= ~CON_PRINTBUFFER;
		}
	}

That puts the onus on the early console to be able to figure out
whether a registering console is its replacement or not; for the x86_64
early_printk, that'd be as simple as comparing the ->name against "ttyS"
or "tty".  It'll be a bit more tricky for PA-RISC, but would solve some
messiness that we could potentially have.  I think that's doable; want
me to try it?

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain