LKML Archive on
help / color / mirror / Atom feed
From: Petr Mladek <>
To: Fengguang Wu <>
Cc: Sergey Senozhatsky <>,
	Kevin Hilman <>,
	Mark Brown <>,
	Greg Kroah-Hartman <>,
	LKML <>,
	Sergey Senozhatsky <>,
	Steven Rostedt <>,
	Linus Torvalds <>
Subject: Re: kernel CI: printk loglevels in kernel boot logs?
Date: Thu, 23 Nov 2017 11:04:04 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed 2017-11-22 20:52:45, Fengguang Wu wrote:
> On Wed, Nov 22, 2017 at 09:38:21PM +0900, Sergey Senozhatsky wrote:
> > On (11/22/17 12:34), Petr Mladek wrote:
> > [..]
> > > > > > This is espeically useful when ingesting kernel logs into advanced
> > > > > > search/analytics frameworks (I'm playing with and ELK stack: Elastic
> > > > > > Search, Logstash, Kibana).
> > [..]
> > > To make it clear. I understand that "show_loglevel" command line argument
> > > would be useful for you. But I am afraid that it is not worth changing
> > > the format. There would need to be wide interest into the change.
> > > Also there would need to be evidence that the existing solutions
> > > (dmesg --raw, console_loglevel) are not enough in many real life
> > > scenarios.
> > 
> > well, I think that that "consoles_format=syslog" command line parameter
> > will be enabled only by those who actually want to have it - Fengguang's
> > build robot and kernelCI (+ may be more setups).  so I'd probably assume
> > there are low risks here. may be I'm wrong.
> Yes, since it needs explicit enabling, local parsers should stay
> working. Unless we send dmesg to other developers, but then they
> might also receive $(dmesg --raw) outputs and need to handle <%u>
> prefixes, too.

I would have agreed with this few days ago. But I am not sure now.

We tried to upstream a feature that allowed to use different clocks
for the printk timestamps. The current one is local clock. Some
people were interested into the real time clock that would allow
to match messages from userspace. Some other users were interested
into boot time clock that would count also the time when the system
is suspended.

We made this configurable (config option + command line option).
I thought that it was safe because local clock stayed default
and the other possibilities would be used just for debugging.

Linus rejected this, see

The feature with timestamps was more complicated. The different time
sources had problems on its own. We had troubles to suggest a good
one. Therefore it was wrong to just move the complex decision to
a poor user.

But one thing is similar. Both features change to format/semantic
of the printed lines (extra field for message level vs. semantic
of the timestamp). In case of the timestamps, Linus was aware
o f a clear userspace dependency (systemd expected time since boot).
The question if there is a user space application that depends
on the message format on the consoles. I have no idea. I would
imagine that there are some system monitors that expect
the strings starting with the timestamp.

You might argue that this will get disabled by default. But
the local clock stayed default in the above feature as well.

One thing is that there is CONFIG_PRINTK_TIME and printk.time
command line option. Therefore the format already is kind
of configurable. But I doubt that this is disabled on
any sane system.

Anyway, I would like to wait a bit for the discussion
about the timestamps feature before we add this
console_format stuff. We still need to discuss
how to pass the timestamps to the user and I would
like to hear Linus' opinion there.

You might want to follow/join the discussion around
alternative approach by Thomas Gleixner, see
It does not solve the userspace side at the moment.

Best Regards,

  parent reply	other threads:[~2017-11-23 10:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
2017-11-22  3:27   ` kernel CI: printk loglevels in kernel boot logs? Fengguang Wu
2017-11-22  5:26     ` Sergey Senozhatsky
2017-11-22 10:42       ` Mark Brown
2017-11-22 11:34     ` Petr Mladek
2017-11-22 12:38       ` Sergey Senozhatsky
2017-11-22 12:52         ` Fengguang Wu
2017-11-23  2:59           ` Sergey Senozhatsky
2017-11-23  3:14             ` Fengguang Wu
2017-11-23  4:31               ` Sergey Senozhatsky
2017-11-29  0:13             ` Kevin Hilman
2017-11-29  7:25               ` Sergey Senozhatsky
2017-11-30 17:45                 ` Kevin Hilman
2017-12-01  1:25                   ` Sergey Senozhatsky
2017-11-23 10:04           ` Petr Mladek [this message]
2017-11-22 20:22         ` Kevin Hilman
2017-11-22 14:10       ` Fengguang Wu
2017-12-05 15:55         ` Petr Mladek
2017-12-05 16:13           ` Sergey Senozhatsky
2017-12-05 20:54           ` Steven Rostedt
2017-12-06 13:54             ` Petr Mladek

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* 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).