Messages in this thread | | | Date | Wed, 16 Mar 2005 13:07:59 +0000 | From | Matthew Wilcox <> | Subject | Re: [PATCH] CON_BOOT |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |