From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: "Frédéric Weisbecker" <fweisbec@gmail.com>,
"Li Zefan" <lizf@cn.fujitsu.com>,
"Arjan van de Ven" <arjan@infradead.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Alan Cox" <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] WARN(): add a \n to the message printk
Date: Mon, 15 Jun 2009 21:04:25 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0906152055580.3282@localhost.localdomain> (raw)
In-Reply-To: <20090615171044.GC25760@elte.hu>
On Mon, 15 Jun 2009, Ingo Molnar wrote:
>
> Nice idea ...
>
> Puts some pressure on current intentionally 'naked' printks (there's
> still a few of them) - but that's OK, it's not like KERN_CONT (or
> pr_cont()) is that hard to add.
I looked some more, and there's a _ton_ of these naked printk's in the
partition handling code.
So while I think the patch was a good idea, I don't feel like exposing
quite that many old printk's and forcing people to use KERN_CONT. Here's
an alternate patch that has a somewhat similar approach, but tries much
harder to leave naked printk's as-is.
So instead of always adding a '\n' if it doesn't say KERN_CONT, it just
adds '\n' if it has a KERN_xyz level. It also modifies the code to _only_
look at the beginning of the printk - if you have a multi-line printk,
it will take the log-level from the beginning of the printk, and nowhere
else.
And it will take the log-level from the beginning of the printk
*regardless* of whether it thinks you're at the beginning of a line or
not.
So with this, KERN_CONT is not as important, but it_is_ meaningful: if you
want to print out something like "<%d>", then you _have_ to have a
KERN_xyz header, and if you don't want to force a new line, you have to do
printk(KERN_CONT "<%d>", n);
because otherwise the printk code will think that what you want to print
out is the loglevel.
But for all the traditional printk()'s that don't have KERN_CONT (or other
loglevel info), and print out strings that are not of that "<.>" form,
they'll still work as they used to.
And no, this does not necessarily fix Arjan's problem: it only adds the
newline before printk's that _do_ have a KERN_<lvl> format. So now, in
order to get the extra '\n' after the WARN_ON() line, somebody needs to
make sure that the printk's in the warning printing have loglevels.
Arjan?
Linus
---
include/linux/kernel.h | 2 +-
kernel/printk.c | 31 ++++++++++++++++++++++---------
2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 883cd44..066bb1e 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -102,7 +102,7 @@ extern const char linux_proc_banner[];
* line that had no enclosing \n). Only to be used by core/arch code
* during early bootup (a continued line is not SMP-safe otherwise).
*/
-#define KERN_CONT ""
+#define KERN_CONT "<c>"
extern int console_printk[];
diff --git a/kernel/printk.c b/kernel/printk.c
index 5052b54..a87770c 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -687,20 +687,33 @@ asmlinkage int vprintk(const char *fmt, va_list args)
sizeof(printk_buf) - printed_len, fmt, args);
+ p = printk_buf;
+
+ /* Do we have a loglevel in the string? */
+ if (p[0] == '<') {
+ unsigned char c = p[1];
+ if (c && p[2] == '>') {
+ switch (c) {
+ case '0' ... '7': /* loglevel */
+ current_log_level = c - '0';
+ if (!new_text_line) {
+ emit_log_char('\n');
+ new_text_line = 1;
+ }
+ /* Fallthrough - skip the loglevel */
+ case 'c': /* KERN_CONT */
+ p += 3;
+ break;
+ }
+ }
+ }
+
/*
* Copy the output into log_buf. If the caller didn't provide
* appropriate log level tags, we insert them here
*/
- for (p = printk_buf; *p; p++) {
+ for ( ; *p; p++) {
if (new_text_line) {
- /* If a token, set current_log_level and skip over */
- if (p[0] == '<' && p[1] >= '0' && p[1] <= '7' &&
- p[2] == '>') {
- current_log_level = p[1] - '0';
- p += 3;
- printed_len -= 3;
- }
-
/* Always output the token */
emit_log_char('<');
emit_log_char(current_log_level + '0');
next prev parent reply other threads:[~2009-06-16 4:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-15 7:08 [PATCH] WARN(): add a \n to the message printk Arjan van de Ven
2009-06-15 9:09 ` Alan Cox
2009-06-15 14:13 ` Arjan van de Ven
2009-06-15 16:38 ` Linus Torvalds
2009-06-15 16:58 ` Linus Torvalds
2009-06-15 17:10 ` Ingo Molnar
2009-06-16 4:04 ` Linus Torvalds [this message]
2009-06-16 4:16 ` Linus Torvalds
2009-06-16 5:46 ` Arjan van de Ven
2009-06-15 17:57 ` Linus Torvalds
2009-06-15 18:39 ` Ingo Molnar
2009-06-15 18:53 ` Frederic Weisbecker
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=alpine.LFD.2.01.0906152055580.3282@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mingo@elte.hu \
/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.