From: Petr Mladek <pmladek@suse.com>
To: Chris Down <chris@chrisdown.name>
Cc: linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
John Ogness <john.ogness@linutronix.de>,
Geert Uytterhoeven <geert@linux-m68k.org>,
kernel-team@fb.com
Subject: Re: design: was: Re: [RFC PATCH v2] printk: console: Allow each console to have its own loglevel
Date: Tue, 19 Jul 2022 15:00:53 +0200 [thread overview]
Message-ID: <YtarBVizQ0ImCKeP@alley> (raw)
In-Reply-To: <Ytafbe6jGQ9sW7HG@chrisdown.name>
On Tue 2022-07-19 13:11:25, Chris Down wrote:
> Chris Down writes:
> > Ok, I will incorporate the EINVAL return for sysctl in a separate patch
> > first, and then add the new sysfs one to the existing changes for v3.
> > :-)
>
> Thinking more about this, I will probably not change the existing
> kernel.printk semantics to return EINVAL, since it could silently(ish) cause
> regressions for existing misconfigured systems on boot. I'll just add the
> clamps to the new controls.
I guess that you are talking about the obsoleted sysctl
'kernel.printk' that has 4 values. And about syslog
behavior. I agree that changing he behavior might be risky.
But I think that we should return EINVAL in the newly added
interface. IMHO, people should know when the entered value
can't be used instead of silently changing it.
When talking about the new interface. I would either do not create
/proc/sys/kernel/minimum_console_loglevel or I would make it read
only. IMHO, this value was supposed to be a built in value and
was exported without much thinking. I guess that only few people know
what it really does and it is better to hide it.
Best Regards,
Petr
prev parent reply other threads:[~2022-07-19 13:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-20 12:57 [RFC PATCH v2] printk: console: Allow each console to have its own loglevel Chris Down
2022-05-20 16:06 ` Rik van Riel
2022-07-07 14:38 ` Petr Mladek
2022-07-13 14:32 ` Chris Down
2022-05-21 18:51 ` Greg Kroah-Hartman
2022-05-21 19:23 ` Chris Down
2022-05-23 13:09 ` Vincent Whitchurch
2022-05-23 14:24 ` Chris Down
2022-06-16 15:57 ` Chris Down
2022-07-08 15:23 ` design: was: " Petr Mladek
2022-07-08 19:04 ` John Ogness
2022-07-11 8:32 ` Petr Mladek
2022-07-11 10:17 ` Sergey Senozhatsky
2022-07-13 14:50 ` Chris Down
2022-07-13 14:49 ` Chris Down
2022-07-14 15:44 ` Petr Mladek
2022-07-15 12:49 ` Petr Mladek
2022-07-15 13:00 ` Chris Down
2022-07-19 12:11 ` Chris Down
2022-07-19 13:00 ` Petr Mladek [this message]
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=YtarBVizQ0ImCKeP@alley \
--to=pmladek@suse.com \
--cc=chris@chrisdown.name \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=john.ogness@linutronix.de \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.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).