Re: [PATCH] Console: fall back to /dev/null when no console is availlable

[Jörn Engel]

On Wed, 6 October 2004 15:55:52 +0200, Geert Uytterhoeven wrote:
> 
> 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)

Correct.  It may be nice have a seperate logic for 1.  'console' is a
good name for 2., so I would keep that.  But then again, I don't care
enough to write a patch.

> 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.
> 
> [...]
>
> > 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.

Which is fair.  So we end up with two devices claiming to be a valid
console, but one of them makes people unhappy.  Are you certain that
*everone* wants to have 'ttyS0' as default console and not 'debug'?

Taking the last one registered is basically random.  If people care
enough, they should explicitly state things on the command line.

Taking the last with input support (or the last, if none support
input) adds some policy.  If people disagree with the kernel policy,
they should explicitly state things...

Policy inside the kernel sounds like a bad idea.  People can already
get what they want, if they...  Policy will help some people with
similar taste, but people with different taste can "argue" against it
and someone has to play judge - not my cup of tea.

Jörn

-- 
Premature optimization is the root of all evil.
-- Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/