All of lore.kernel.org
 help / color / mirror / Atom feed
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');

  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.