patch: print out msg level on printk

[ron minnich]

This patch provides output like this:
<8>dynamic PCI: 00:0b.1(PCI: 00:0b.1): enabled 1 have_resources 1 initialized 1
<7>Stage2 code done.
<6>LAR: Attempting to open 'normal/payload/segment0'.
<8>LAR: Start 0xfff80000 len 0x80000
<8>LAR: seen member normal/option_table@0xfff80000, size 1776
<8>LAR: seen member normal/initram/segment0@0xfff80740, size 31644

We can thus get SPEW data but then easily filter it by log level.

Index: lib/console.c
===================================================================
--- lib/console.c	(revision 884)
+++ lib/console.c	(working copy)
@@ -136,8 +136,14 @@
    	return 0;
    }

+	console_tx_byte('<', (void *)0);
+	console_tx_byte(msg_level + '0', (void *)0);
+	console_tx_byte('>', (void *)0);
+
+	i = 3;
+
    va_start(args, fmt);
-	i = vtxprintf(console_tx_byte, (void *)0, fmt, args);
+	i += vtxprintf(console_tx_byte, (void *)0, fmt, args);
    va_end(args);

return i;

Signed-off-by: Ronald G. Minnich

But better code is welcome.

ron

[Carl-Daniel Hailfinger]

On 05.10.2008 07:29, ron minnich wrote:
> This patch provides output like this:
> <8>dynamic PCI: 00:0b.1(PCI: 00:0b.1): enabled 1 have_resources 1 initialized 1
> <7>Stage2 code done.
> <6>LAR: Attempting to open 'normal/payload/segment0'.
> <8>LAR: Start 0xfff80000 len 0x80000
> <8>LAR: seen member normal/option_table@0xfff80000, size 1776
> <8>LAR: seen member normal/initram/segment0@0xfff80740, size 31644
>
> We can thus get SPEW data but then easily filter it by log level.

AFAICS this will look strange for multiline and half-line printk statements.
Hm. We could check whether the last printed character was \n and add the
prefix only then. That fixes the half-line case.
The multiline case is a bit more difficult.

I'll look into this over the next few days if you don't beat me to it.

Regards,
Carl-Daniel

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 05.10.2008 07:29, ron minnich wrote:
> > This patch provides output like this:
> > <8>dynamic PCI: 00:0b.1(PCI: 00:0b.1): enabled 1 have_resources 1 initialized 1
> > <7>Stage2 code done.
> > <6>LAR: Attempting to open 'normal/payload/segment0'.
> > <8>LAR: Start 0xfff80000 len 0x80000
> > <8>LAR: seen member normal/option_table@0xfff80000, size 1776
> > <8>LAR: seen member normal/initram/segment0@0xfff80740, size 31644
> >
> > We can thus get SPEW data but then easily filter it by log level.
>
> AFAICS this will look strange for multiline and half-line printk statements.
> Hm. We could check whether the last printed character was \n and add the
> prefix only then. That fixes the half-line case.
> The multiline case is a bit more difficult.

I think printing the log level makes sense only if there's a klogd
running on the other side. But I don't particularly care either. It
should be an option, and yes, it should be fixed the way Carl-Daniel
suggests, if it goes in.

Stefan

[ron minnich]

On Sun, Oct 5, 2008 at 3:54 PM, Stefan Reinauer  wrote:
> I think printing the log level makes sense only if there's a klogd
> running on the other side. But I don't particularly care either. It
> should be an option, and yes, it should be fixed the way Carl-Daniel
> suggests, if it goes in.

it's handy for debug. You can print at SPEW, and then easily run the
text through a filter to get DEBUG or less.

I'm not that worried about it going in; I can keep my own version
handy. It's already proving to be very nice for me.

ron

[Jordan Crouse]

On 06/10/08 00:54 +0200, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
> > On 05.10.2008 07:29, ron minnich wrote:
> > > This patch provides output like this:
> > > <8>dynamic PCI: 00:0b.1(PCI: 00:0b.1): enabled 1 have_resources 1 initialized 1
> > > <7>Stage2 code done.
> > > <6>LAR: Attempting to open 'normal/payload/segment0'.
> > > <8>LAR: Start 0xfff80000 len 0x80000
> > > <8>LAR: seen member normal/option_table@0xfff80000, size 1776
> > > <8>LAR: seen member normal/initram/segment0@0xfff80740, size 31644
> > >
> > > We can thus get SPEW data but then easily filter it by log level.
> >
> > AFAICS this will look strange for multiline and half-line printk statements.
> > Hm. We could check whether the last printed character was \n and add the
> > prefix only then. That fixes the half-line case.
> > The multiline case is a bit more difficult.
>
> I think printing the log level makes sense only if there's a klogd
> running on the other side. But I don't particularly care either. It
> should be an option, and yes, it should be fixed the way Carl-Daniel
> suggests, if it goes in.

In v3, we will eventually have a klogd of sorts - Uwe has already 
written a coreinfo reader for the bootlog, and we are a single 
reserved memory hole away from reading it in the kernel too.

Jordan