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

[Geert Uytterhoeven]

On Sun, 26 Aug 2007, Mike Frysinger wrote:
> On 8/26/07, Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > On Fri, 24 Aug 2007, Joe Perches wrote:
> > > Corrected printk calls with multiple output lines which
> > > did not correctly preface each line with KERN_<level>
> > >
> > > Fixed uses of some single lines with too many KERN_<level>
> >
> > > --- a/arch/arm/kernel/ecard.c
> > > +++ b/arch/arm/kernel/ecard.c
> > > @@ -547,7 +547,8 @@ static void ecard_check_lockup(struct irq_desc *desc)
> > >       if (last == jiffies) {
> > >               lockup += 1;
> > >               if (lockup > 1000000) {
> > > -                     printk(KERN_ERR "\nInterrupt lockup detected - "
> > > +                     printk(KERN_ERR "\n"
> > > +                            KERN_ERR "Interrupt lockup detected - "
> > >                              "disabling all expansion card interrupts\n");
> > >
> > >                       desc->chip->mask(IRQ_EXPANSIONCARD);
> >
> > What's the purpose of having lines printed with e.g. `KERN_ERR "\n"' only?
> > Shouldn't these just be removed?
> >
> > Usually lines starting with `\n' are continuations, but given some other
> > module may call printk() in between, there's no guarantee continuations
> > appear on the same line.
> 
> erm, i thought the prink lock was grabbed per-buffer, not per-line ...
> so yes, if the function calls were like printk(KERN_ERR "\n");
> printk(KERN_ERR "..."); things could be broken up, but this is on
> function call, so it shouldnt ...

Yes it is.

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.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds