From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: "Calvin Owens" <calvinowens@fb.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jiri Slaby" <jslaby@suse.cz>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Manuel Schölling" <manuel.schoelling@gmx.de>,
"Hans de Goede" <hdegoede@redhat.com>,
"Paul Burton" <paul.burton@imgtec.com>,
linux-kernel@vger.kernel.org, kernel-team@fb.com,
"Sergey Senozhatsky" <sergey.senozhatsky@gmail.com>
Subject: Re: [RFC][PATCH 1/2] printk: Introduce per-console filtering of messages by loglevel
Date: Wed, 5 Apr 2017 17:22:56 +0200 [thread overview]
Message-ID: <20170405152256.GS3452@pathway.suse.cz> (raw)
In-Reply-To: <20170405021628.GC11669@jagdpanzerIV.localdomain>
On Wed 2017-04-05 11:16:28, Sergey Senozhatsky wrote:
> On (04/05/17 11:08), Sergey Senozhatsky wrote:
> [..]
> > > stop_critical_timings(); /* don't trace print latency */
> > > - call_console_drivers(ext_text, ext_len, text, len);
> > > + call_console_drivers(ext_text, ext_len, text, len, msg->level);
> > > start_critical_timings();
> > > printk_safe_exit_irqrestore(flags);
> >
> > ok, so the idea is quite clear and reasonable.
> >
> >
> > some thoughts,
> > we have a system-wide suppress_message_printing() loglevel filtering
> > in console_unlock() loop, which sets a limit on loglevel for all of
> > the messages - we don't even msg_print_text() if the message has
> > suppressible loglevel. and this implicitly restricts per-console
> > maxlevels.
> >
> > console_unlock()
> > {
> > for (;;) {
> > ...
> > skip:
> >
> > if (suppress_message_printing(msg->level)) // console_loglevel
> > goto skip;
> >
> > call_console_drivers(msg->level)
> > {
> > if (level > con->maxlevel) // con loglevel
> > continue;
> > ...
> > }
> > }
> > }
> >
> > this can be slightly confusing. what do you think?
>
> one more thing.
>
> this per-console filtering ignores... the "ignore_loglevel" param.
>
> early_param("ignore_loglevel", ignore_loglevel_setup);
> module_param(ignore_loglevel, bool, S_IRUGO | S_IWUSR);
> MODULE_PARM_DESC(ignore_loglevel,
> "ignore loglevel setting (prints all kernel messages to the console)");
>
>
> my preference would be preserve "ignore_loglevel" behaviour. if
> we are forced to 'ignore all loglevel filtering' then we should
> do so.
I think about a reasonable behavior. There seems to be three variables
that are related and are in use:
console_level
minimum_console_loglevel
ignore_loglevel
The functions seems to be the following:
+ console_level defines the current maximum level of
messages that appear on all enabled consoles; it
allows to filter out less important ones
+ minimum_console_loglevel defines the minimum
console_loglevel that might be set by userspace
via syslog interface; it prevents userspace from
hiding emergency messages
+ ignore_loglevel allows to see all messages
easily; it is used for debugging
IMPORTANT: console_level is increased in some special
situations to see everything, e.g. in panic(), oops_begin(),
__handle_sysrq().
I guess that people want to see all messages even on the slow
console during panic(), oops(), with ignore_loglevel. It means
that the new per-console setting must not limit it. Also
any console must not go below minimum_console_level.
What about doing it the other way and define min_loglevel
for each console. It might be used to make selected consoles
always more verbose (above current console_level) but it
will not limit the more verbose modes.
Best Regards,
Petr
next prev parent reply other threads:[~2017-04-05 15:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-04 23:02 [RFC][PATCH 1/2] printk: Introduce per-console filtering of messages by loglevel Calvin Owens
2017-04-04 23:03 ` [RFC][PATCH 2/2] printk: Add /sys/consoles/${con}/ and maxlevel attribute Calvin Owens
2017-04-05 3:30 ` Steven Rostedt
2017-04-05 23:55 ` Calvin Owens
2017-04-05 1:51 ` [RFC][PATCH 1/2] printk: Introduce per-console filtering of messages by loglevel Joe Perches
2017-04-05 2:08 ` Sergey Senozhatsky
2017-04-05 2:16 ` Sergey Senozhatsky
2017-04-05 3:27 ` Steven Rostedt
2017-04-05 23:53 ` Calvin Owens
2017-04-05 15:22 ` Petr Mladek [this message]
2017-04-06 0:38 ` Calvin Owens
2017-04-06 14:02 ` Petr Mladek
2017-04-06 22:52 ` Calvin Owens
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=20170405152256.GS3452@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=calvinowens@fb.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=jslaby@suse.cz \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manuel.schoelling@gmx.de \
--cc=paul.burton@imgtec.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.