[lkml]   [2017]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kernel CI: printk loglevels in kernel boot logs?
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.

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`


 \ /
  Last update: 2017-11-22 13:53    [W:0.145 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site