[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201008105603.GB554@jagdpanzerIV.localdomain>
Date: Thu, 8 Oct 2020 19:56:03 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To: Petr Mladek <pmladek@...e.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Guenter Roeck <linux@...ck-us.net>,
Shreyas Joshi <shreyas.joshi@...mp.com>, rostedt@...dmis.org,
shreyasjoshi15@...il.com, linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] printk: handle blank console arguments passed in.
On (20/10/08 11:01), Petr Mladek wrote:
>
> Interesting idea. Well, it looks like yet another mess:
>
> + it would show the consoles in /proc/consoles
> even thought they will be basically unusable
Which is fine, no? We already can have disables consoles in
/proc/consoles.
$ cat /proc/consoles
tty0 -WU ( C p ) 4:1
So tty0 is not 'E'-enabled. I see no problems with that.
These are the flags that /proc/consoles handle
con_flags[] = {
{ CON_ENABLED, 'E' },
{ CON_CONSDEV, 'C' },
{ CON_BOOT, 'B' },
{ CON_PRINTBUFFER, 'p' },
{ CON_BRL, 'b' },
{ CON_ANYTIME, 'a' },
};
Why do you think that having disabled consoles in /proc/consoles
is a mess?
> IMHO, we should try to understand why it actually crashes first.
> It might help to solve the problem some cleaner way.
Well, I guess, we have files (either regular files or devices) sitting
in fd-s 0,1,2. God knows what mount/fsck/modprobe can fprintf(), for
instance, to stdout/stderr and what they can corrupt.
-ss
Powered by blists - more mailing lists