Messages in this thread | | | Date | Wed, 6 Oct 2004 15:55:52 +0200 (MEST) | From | Geert Uytterhoeven <> | Subject | Re: [PATCH] Console: fall back to /dev/null when no console is availlable |
| |
On Wed, 6 Oct 2004, [iso-8859-1] Jörn Engel wrote: > On Wed, 6 October 2004 15:07:05 +0200, Geert Uytterhoeven wrote: > > On Wed, 6 Oct 2004, [iso-8859-1] Jörn Engel wrote: > > > Point is that above patch is simpler and empiria didn't give me a > > > reason to worry about anything else. > > > > I'll give you another reason :-) > > > > If I do have multiple active struct consoles registered (e.g. normal tty0 or > > ttyS0 and a debug console without a real tty), and the /dev/console demux > > thinks the debug console is the real one (the one opened if you open > > /dev/console), printk() messages will appear on both active consoles, but > > /dev/console cannot be opened. > > > > To avoid this problem, the /dev/console demux should walk the list of active > > consoles until it finds one that can be opened, or fall back to /dev/null if > > none is found. > > > > Does that sound reasonable? > > Not to me, no. But I was wrong before. > > Having no console at all is a valid design. It used to cause
One problem is that `console' means multiple things: 1. The output device for printk() (multiple consoles are allowed, cfr. multiple console= kernel parameters and debug-only consoles) 2. The tty (both input and output) for /sbin/init (only one instance, cfr. the last console= kernel parameter)
I suggested to change the logic for 2 not to use the last console= kernel parameter if it turns out not to support input (cfr. the return value of struct console.device()), but try the other registered struct consoles.
> problems, my patch fixes them. A command-line option like > "console=/dev/null" doesn't fix it because it doesn't do what it > appears to do at first glance, so the patch is needed.
Indeed. Because the /dev/null driver doesn't call register_console(). It could be made to work that way (`console=null'), though, but make sure to register your null-console _first_. But I think it's simpler to just check console->device() and take appropriate actions.
> Having a non-working console, esp. for debug, is a rather odd design. > My approach would be to either explicitly tell the kernel to use the > other as default console via "console=/dev/ttyS0" or not have the > debug thing in the kernel in the first place. Either way, no patch is > needed.
It was not `designed' to be that way. But due to how `the console' (nr. 2 from above) works, registration order matters. If people make the mistake (or just forget) to say `console=ttyS0', a debug console registered later causes problems.
And the reason the debug consoles (read: capturers) use register_console() is to avoid code duplication.
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds | |