Re: [PATCH] Prefix each line of multiline printk(KERN_<level> "foo\nbar") with KERN_<level>
"Maciej W. Rozycki" <[email protected]> Wed, 29 Aug 2007 12:22:41 +0100 (BST)
| Newsgroups | gmane.linux.kernel,gmane.linux.redhat.blinux.general,gmane.linux.cluster.redhat.cluster.devel,gmane.linux.ports.x86-64.general,gmane.linux.file-systems.jffs,gmane.linux.acpi.devel,gmane.linux.ide,gmane.linux.kernel.mm,gmane.linux.drivers.mtd,gmane.linux.scsi,gmane.linux.network,gmane.linux.ports.hppa,gmane.linux.hardware.blackfin.kernel.devel |
|---|---|
| Message-ID | <[email protected]> |
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.
Maciej