Re: kernel CI: printk loglevels in kernel boot logs?

From: Fengguang Wu
Date: Wed Nov 22 2017 - 07:52:54 EST


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 think it makes sense to have syslog's format "<%u>[timestamp] text\n"
on serial consoles (time stamp when PRINTK_TIME set; <%u> when
consoles_format=syslog set).

Thanks. Since the 0day scripts can already parse that format (code
is listed below), we should quickly benefit from that feature when
it's mainlined.

https://github.com/fengguang/lkp-tests/blob/master/lib/dmesg.rb

oops = `#{grep} -a -E -e '^<[0123]>' -e '^kern :(err |crit |alert |emerg ): ' #{kmsg_file} |
sed -r 's/\\x1b\\[([0-9;]+m|[mK])//g' |
grep -a -v -E -f #{LKP_SRC}/etc/oops-pattern |
grep -a -v -F -f #{LKP_SRC}/etc/kmsg-blacklist`

Thanks,
Fengguang