LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Petr Mladek <firstname.lastname@example.org> To: Fengguang Wu <email@example.com> Cc: Sergey Senozhatsky <firstname.lastname@example.org>, Kevin Hilman <email@example.com>, Mark Brown <firstname.lastname@example.org>, Greg Kroah-Hartman <email@example.com>, LKML <firstname.lastname@example.org>, Sergey Senozhatsky <email@example.com>, Steven Rostedt <firstname.lastname@example.org>, Linus Torvalds <email@example.com> Subject: Re: kernel CI: printk loglevels in kernel boot logs? Date: Thu, 23 Nov 2017 11:04:04 +0100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> 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 https://lkml.kernel.org/r/CA+55aFwUfA__6MgMgjENnx+_RYY2ZOOLiSx2ea1AvYhSZN+78A@mail.gmail.com https://lkml.kernel.org/r/CA+55aFzLH9crdMtUFkD-PtNGuxu_fsG5GH2ACni69ug9iMfirstname.lastname@example.org https://lkml.kernel.org/r/CA+55aFzzvBD4_WYm-5Bm7TeRGR8nNu1oz0oWNcRNmTNJm=M4Lw@mail.gmail.com 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 https://email@example.com It does not solve the userspace side at the moment. Best Regards, Petr
next prev 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] <CAOi56cVORdyjTXK4QGYRfyD1Q=QBgsU3B__gZT0xj6OBKaasLQ@mail.gmail.com> [not found] ` <firstname.lastname@example.org> 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: 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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: linkBe 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).