[Top] [All Lists]

Re: [PATCH] Prefix each line of multiline printk(KERN_<level> "foo\nbar"

To: Geert Uytterhoeven <>
Subject: Re: [PATCH] Prefix each line of multiline printk(KERN_<level> "foo\nbar") with KERN_<level>
From: "Maciej W. Rozycki" <>
Date: Wed, 29 Aug 2007 12:22:41 +0100 (BST)
Cc: Mike Frysinger <>, Joe Perches <>,,,,,,,,,,,,,,,,,
In-reply-to: <Pine.LNX.4.64.0708261305020.31149@anakin>
Original-recipient: rfc822;
References: <1187999098.32738.179.camel@localhost> <Pine.LNX.4.64.0708261028120.31149@anakin> <> <Pine.LNX.4.64.0708261305020.31149@anakin>
On Sun, 26 Aug 2007, Geert Uytterhoeven wrote:

> What I mean is that probably there used to be a printk() call starting with
> `\n'. Then someone added a `KERN_ERR' in front of it.

 I gather '\n' at the beginning is to assure the following line is output 
on a separate line rather than as a continuation of another one which may 
have been output without a trailing '\n'.  A situation where printk() is 
called with a string containing no trailing '\n' may be discouraged, but 
there are some more or less justified exceptions.  For example the SCSI 
disk spin-up code is one.

 Therefore it may be reasonable for more critical messages -- perhaps not 
ones at KERN_ERR, but certainly KERN_CRIT and higher ones -- that may 
potentially happen asynchronously to start with '\n'.  In this case a call 
would look like this:

        printk("\n" KERN_CRIT "The actual message.\n");

Of course based on "console_loglevel" and "default_message_level" the 
leading '\n' may still get swallowed from what gets printed to the console 
terminal, but in reality I do not think that poses a problem, as these 
both can be set by a system administrator according to the local policy.


<Prev in Thread] Current Thread [Next in Thread>