From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Willy Tarreau <willy@w.ods.org>,
Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>,
Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Console: fall back to /dev/null when no console is availlable
Date: Wed, 6 Oct 2004 15:33:10 +0200 [thread overview]
Message-ID: <20041006133310.GD8386@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <Pine.GSO.4.61.0410061504140.20160@waterleaf.sonytel.be>
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
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.
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.
Worse, a kernel patch would paper over what is an underlying problem
in my book. Fix the first problem, don't live with it as good as
possible.
Is this reasonable?
Jörn
--
The competent programmer is fully aware of the strictly limited size of
his own skull; therefore he approaches the programming task in full
humility, and among other things he avoids clever tricks like the plague.
-- Edsger W. Dijkstra
next prev parent reply other threads:[~2004-10-06 13:33 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-05 18:52 [PATCH] Console: fall back to /dev/null when no console is availlable Jörn Engel
2004-10-05 20:27 ` Russell King
2004-10-05 21:06 ` Greg KH
2004-10-05 21:13 ` Russell King
2004-10-06 15:00 ` Alan Cox
2004-10-06 17:41 ` Greg KH
2004-10-06 18:01 ` Jörn Engel
2004-10-06 18:18 ` Greg KH
2004-10-06 19:20 ` Jörn Engel
2004-10-06 18:26 ` Chris Wright
2004-10-06 18:16 ` Andries Brouwer
2004-10-06 19:18 ` Alan Cox
2004-10-06 20:54 ` Greg KH
2004-10-06 20:29 ` Alan Cox
2004-10-06 21:45 ` Russell King
2004-10-07 5:51 ` Valdis.Kletnieks
2004-10-08 2:15 ` Herbert Xu
2004-10-06 20:01 ` Russell King
2004-10-05 22:36 ` Andries Brouwer
2004-10-06 6:43 ` Russell King
2004-10-07 14:41 ` Jan-Benedict Glaw
2004-10-05 21:58 ` Denis Vlasenko
2004-10-06 4:34 ` Willy Tarreau
2004-10-06 8:43 ` Geert Uytterhoeven
2004-10-06 12:15 ` Jörn Engel
2004-10-06 13:07 ` Geert Uytterhoeven
2004-10-06 13:33 ` Jörn Engel [this message]
2004-10-06 13:55 ` Geert Uytterhoeven
2004-10-06 14:12 ` Jörn Engel
2004-10-06 14:23 ` Geert Uytterhoeven
2004-10-06 15:28 ` Jörn Engel
2004-10-06 15:36 ` Geert Uytterhoeven
2004-10-06 15:51 ` Jörn Engel
2004-10-05 23:30 ` Andrew Morton
2004-10-06 12:16 ` Jörn Engel
2004-10-06 17:38 ` Greg KH
2004-10-06 18:04 ` Jörn Engel
2004-10-06 18:19 ` Greg KH
2004-10-06 19:23 ` Jörn Engel
2004-10-06 21:22 ` Thayne Harbaugh
2004-10-07 8:18 ` Geert Uytterhoeven
2004-10-07 9:07 ` Russell King
2004-10-07 9:46 ` Geert Uytterhoeven
2004-10-06 18:37 ` Gianni Tedesco
2004-10-06 19:08 ` Jörn Engel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041006133310.GD8386@wohnheim.fh-wedel.de \
--to=joern@wohnheim.fh-wedel.de \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
--cc=willy@w.ods.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox