Re: [RFC 1/2] printk: Add kernel parameter: mute_console

[John Ogness <john.ogness@linutronix.de>]

On 2020-10-22, Guenter Roeck <linux@roeck-us.net> wrote:
>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>>> index 02d4adbf98d2..52b9e7f5468d 100644
>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>> @@ -2974,6 +2974,12 @@
>>>  			Used for mtrr cleanup. It is spare mtrr entries number.
>>>  			Set to 2 or more if your graphical card needs more.
>>>  
>>> +	mute_console	[KNL]
>>> +			Completely disable printing of kernel messages to
>>> +			the console. It can still be used as stdin, stdout,
>
> "to all consoles"
>
>>> +			and stderr for the init process. Also it can be used
>>> +			for login.
>> 
>> IMHO it would make more sense for this to be a console option:
>> 
>>     console=ttyS0,115200,mute
>> 
>> Then other consoles could still exist that are not muted.
>> 
> Then why specify this console in the first place ?

Because you may still want to use it for stdin/stdout/stderr of PID 1
and/or logins. I understood "mute" as meaning the user does not want to
see kernel logging. But everything else should still work as usual.

>> On a side note, I am considering proposing something similar for my
>> printk-rework efforts. Once console printers are moved to kthreads, some
>> users may not care about latencies and instead prefer synchronous
>> printing. My idea for this is to provide a "sync" option for the
>> console:
>> 
>>     console=ttyS0,115200,sync
>
> The whole point of the exercise is to disable all consoles, including
> default ones which are not explicitly specified on the command line.

In that case I think specifying something like:

    console=null

makes that most sense. I think implementing a "null console" driver
would be quite simple. Then there would be no need for special handling
in the printk subsystem.

John Ogness