linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Shreyas Joshi <shreyas.joshi@biamp.com>,
	rostedt@goodmis.org, shreyasjoshi15@gmail.com,
	linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] printk: handle blank console arguments passed in.
Date: Thu, 22 Oct 2020 22:32:28 +0900	[thread overview]
Message-ID: <20201022133228.GA160085@jagdpanzerIV.localdomain> (raw)
In-Reply-To: <20201022113805.GA32486@alley>

On (20/10/22 13:38), Petr Mladek wrote:
> > Hmm. How about this. console= is undocumented and unspecified - it
> > may work sometimes or it may kill the system (and theoretically even
> > corrupt some files, depending on what fd 1 and fd 2 point to). So
> > maybe we can document console= and handle it in printk, rather than
> > somewhere deep in init/main.c
> 
> I have dig more into it. If I get it correctly, /dev/console is really
> used as stdin, stdout, and stderr for the init process. It has been
> like this from the very beginning.
> 
> In theory, it might be possible to fallback into /dev/null. But it
> would not solve the problem when anyone tries to use /dev/console
> later.
> 
> IMHO, creating /dev/console really _should not_ fail. It means
> that we should register some console.

Yes, I didn't find out exactly why the kernel panics yet. Got
interrupted. What I did notice (when we don't have stdin/out/err)
was init process installing "/" as fd 0, and then doing things
like fprintf(stderr, "running early hook"), perhaps some of those
fprintf()-s end up in the wrong place.

> > IOW add one more flag (yeah, I know) and set it when console_setup()
> > sees console= boot param. The idea is allow console registration,
> > but all consoles should be disabled (cleared CON_ENABLED bit). This
> > would be easier to document, at least.
> 
> It seems that introducing a new option/flag is the best solution
> after all. All other flags are manipulated on different situations
> and it would not be easy to define a sane behavior.
> 
> I like the proposed "mute_consoles". Well, I have it associated rather
> with CONSOLE_LOGLEVEL_SILENT than with disabled console.
> 
> I have played with it and am going to send two patches as RFC.

Cool, thanks. I'll reply to that RFC patch set; there are some
more ideas, that we can discuss.

	-ss

  reply	other threads:[~2020-10-22 13:32 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-09  5:29 [PATCH] printk: handle blank console arguments passed in Shreyas Joshi
2020-03-17  1:34 ` Shreyas Joshi
2020-03-17  1:39   ` Steven Rostedt
2020-03-17  2:01     ` Sergey Senozhatsky
2020-03-17  2:17       ` Shreyas Joshi
2020-03-17  8:22         ` Sergey Senozhatsky
2020-05-22  6:46   ` Shreyas Joshi
2020-05-22  6:53   ` Shreyas Joshi
2020-05-22 10:00     ` Petr Mladek
2020-10-06  2:59       ` Sergey Senozhatsky
2020-10-06  3:35         ` Guenter Roeck
2020-10-06  5:08           ` Greg Kroah-Hartman
2020-10-06 11:17             ` Guenter Roeck
2020-10-06  6:59           ` Sergey Senozhatsky
2020-10-06  9:54             ` Petr Mladek
2020-10-06 13:33               ` Sergey Senozhatsky
2020-10-06 14:22                 ` Guenter Roeck
2020-10-06 16:08                   ` Sergey Senozhatsky
2020-10-06  9:52           ` Petr Mladek
2020-10-06 10:45             ` Guenter Roeck
2020-10-06 13:43               ` Petr Mladek
2020-10-06 16:35                 ` Petr Mladek
2020-10-06 17:15                   ` Sergey Senozhatsky
2020-10-07  7:28                     ` Petr Mladek
2020-10-07 12:30                       ` Sergey Senozhatsky
2020-10-07 14:39                         ` Sergey Senozhatsky
2020-10-07 15:57                         ` Guenter Roeck
2020-10-07 16:29                           ` Sergey Senozhatsky
2020-10-08  5:52                             ` Sergey Senozhatsky
2020-10-08  9:01                               ` Petr Mladek
2020-10-08 10:56                                 ` Sergey Senozhatsky
2020-10-08 12:05                                 ` Sergey Senozhatsky
2020-10-22 11:38                               ` Petr Mladek
2020-10-22 13:32                                 ` Sergey Senozhatsky [this message]
2020-10-08  8:50                         ` Petr Mladek
2020-10-08 12:20                           ` Sergey Senozhatsky
2020-10-08 12:37                             ` Sergey Senozhatsky
2020-05-15 15:24 ` Petr Mladek
2020-05-20 11:50   ` Sergey Senozhatsky
2020-05-22  6:40     ` Shreyas Joshi

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=20201022133228.GA160085@jagdpanzerIV.localdomain \
    --to=sergey.senozhatsky@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=shreyas.joshi@biamp.com \
    --cc=shreyasjoshi15@gmail.com \
    --cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).