Re: [PATCH] printk: Add loglevel for "do not print to consoles".

[Tetsuo Handa]

On 2020/05/13 21:19, Petr Mladek wrote:
> On Wed 2020-05-13 20:24:24, Tetsuo Handa wrote:
>> On 2020/05/13 19:49, Michal Hocko wrote:
>>> On Wed 13-05-20 12:04:13, Petr Mladek wrote:
>>>> What is so special about  OOM dump task so that it would deserve such
>>>> complications?
>  
>> I don't think dump_tasks() is important information to be printed on consoles.
>> But since somebody might think dump_tasks() is important information to be
>> printed on consoles, I suggest switching KERN_NO_CONSOLES using e.g. sysctl.
> 
> You might achieve the same with DEBUG loglevel. Or do I miss anything?

Use of KERN_DEBUG affects userspace syslog daemon. We will have to ask administrators
to configure syslog daemon not to filter KERN_DEBUG messages. And administrators will
be bothered by needless KERN_DEBUG messages. Also,

> 
> [*] It will have no effect when it was disabled by a sysfs knob.

we will have to ask people to "don't make pr_debug() no-op" or
"use KERN_DEBUG instead of pr_debug()".

Your suggestion to change KERN_$LOGLEVEL keeps bothering people. That's bad.

> I know that it is meant as a modifier, like LOGLEVEL_SCHED and
> KERN_CONT.

Right. KERN_NO_CONSOLES is a modifier.

>            But this is another reason to avoid it. We already have
> huge pain with these two modifiers. They both do not work well.

KERN_NO_CONSOLES can not cause pains like LOGLEVEL_SCHED because
KERN_NO_CONSOLES is to say "no need to call console drivers" while
LOGLEVEL_SCHED is to say "don't call console drivers now but have
to call console drivers later".

On 2020/05/13 21:34, Petr Mladek wrote:
> On Wed 2020-05-13 20:03:53, Tetsuo Handa wrote:
>> On 2020/05/13 19:04, Petr Mladek wrote:
>>>> What is wrong with adding NO_CONSOLES ?
>>>
>>> How does it differ from KERN_DEBUG? The debug messages:
>>>
>>>   + can be disabled via sysfs
>>>   + might reach console when this loglevel is enabled
>>
>> KERN_NO_CONSOLES is different from KERN_DEBUG in that KERN_NO_CONSOLES
>> itself does not affect userspace daemon's judgement (whether to filter
>> KERN_$LOGLEVEL messages).
> 
> And that is the evil thing about it. It goes around the loglevel
> filtering.
> 
> The administrator wants to decide what messages are important for him.

Right.

> NO_CONSOLES would mess with this decision. Some messages would suddenly
> get hidden on console but appear in userspace.

Wrong. Console loglevel is already hiding some messages.

>                                                Users would need to
> investigate what the hell is happening. They would need to find the
> new sysfs knob to restore the expected behavior, etc.

That's part of deciding what messages are important for him, as well as
deciding what KERN_$LOGLEVEL messages are worth printing to consoles.