On Thu 2020-10-08 14:52:38, Sergey Senozhatsky wrote:
> On (20/10/08 01:29), Sergey Senozhatsky wrote:
> > On (20/10/07 08:57), Guenter Roeck wrote:
> > > On 10/7/20 5:30 AM, Sergey Senozhatsky wrote:
> >
> > [..]
> >
> > > I can see to options: Link /dev/console to /dev/null if there is no
> > > console,
> > > or do something like
> > >
> > > if (IS_ERR(file)) {
> > > pr_warn("Warning: unable to open an initial console.\n");
> > > file = filp_open("/dev/null", O_RDWR, 0);
> > > if (IS_ERR(file))
> > > return;
> > > }
> >
> > As far as I can tell, /dev/null does not exist yet on this stage
> > (at least not in my system). But generally the idea looks interesting.
>
> 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
>
> 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.
>
> Schematically:
>
> ---
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 929e86a01148..b71ff9d87693 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -281,6 +281,7 @@ static struct console_cmdline
> console_cmdline[MAX_CMDLINECONSOLES];
>
> static int preferred_console = -1;
> static bool has_preferred_console;
> +static bool mute_consoles = false;
> int console_set_on_cmdline;
> EXPORT_SYMBOL(console_set_on_cmdline);
>
> @@ -2141,6 +2142,9 @@ static int __add_preferred_console(char *name, int idx,
> char *options,
> struct console_cmdline *c;
> int i;
>
> + if (mute_consoles)
> + return;
> +
> /*
> * See if this tty is not yet registered, and
> * if we have a slot free.
Interesting idea. Well, it looks like yet another mess:
+ it would show the consoles in /proc/consoles
even thought they will be basically unusable
+ it is yet another way to affect the amount of messages
on console. We already have console_loglevel, ignore_loglevel.
+ this effect is far from obvious when using console=""
IMHO, we should try to understand why it actually crashes first.
It might help to solve the problem some cleaner way.
Thanks a lot for digging into it.
Best Regards,
Petr
