Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] printk: Add loglevel for "do not print to consoles".
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        linux-kernel@vger.kernel.org, Dmitry Safonov <dima@arista.com>,
        Michal Hocko <mhocko@suse.com>,
        Yafang Shao <laoar.shao@gmail.com>
References: <20200424024239.63607-1-penguin-kernel@I-love.SAKURA.ne.jp>
 <20200424092816.62a61b1d@gandalf.local.home>
 <579fbe97-9aae-2b67-03ff-01291b9cbb7d@i-love.sakura.ne.jp>
 <20200424103131.7987f890@gandalf.local.home>
 <7ec0b0a3-39ae-0f1c-b8c2-e1e9e60f1223@i-love.sakura.ne.jp>
 <20200424114225.5a3bab7e@gandalf.local.home>
From:   Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Message-ID: <d967cd75-f61d-291a-81e9-1da76e4179c2@i-love.sakura.ne.jp>
Date:   Sat, 25 Apr 2020 01:10:15 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200424114225.5a3bab7e@gandalf.local.home>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2020/04/25 0:42, Steven Rostedt wrote:
> You can also use the tracing ring buffer for this, as it has been safe in
> all these contexts for a very long time. And that ring buffer is something
> that you can use outside of tracing (oprofile uses it).

Some messages are read from printk() source and other messages are read from
non-printk() source will loose ordering of messages (i.e. non-understandable
log files). For those who analyze log files, multiple sources are not acceptable.

> And both shouldn't be done within the kernel. The "CONSOLE_LOGLEVEL_SILENT"
> if for user decided policy, not the kernel making that policy for the user.

KERN_NO_CONSOLES is a mechanism for implementing user decided policy. As long as
userspace can control whether to use KERN_NO_CONSOLES (e.g. sysctl), there should
be no problem with adding KERN_NO_CONSOLES (i.e. this patch) to the kernel side.