[PATCH v3 2/5] ARM: Add a printk loglevel modifier

[arnd@arndb.de (Arnd Bergmann)]

On Wednesday 14 March 2012, Uwe Kleine-K?nig wrote:
> I don't get your reasoning here.
> 
> An (independant) printk (that is expected to start at a new line) must
> start with KERN_SOMETHING iff the previous printk always ends in \n?
> Probably not. 
> 
> Independently of the correctness of the first patch that splits the
> printk I'm just taking it as an example:
> 
> In this case the two printks in question are:
> 
>                 printk("CPU: %s [%08x] revision %d (ARMv%s)", ...);
>         #ifdef CONFIG_CPU_CP15
>                 printk(KERN_CONT ", cr=%08lx\n", cr_alignment);
>         #endif
> 
> and
> 
>                 printk("CPU: %s data cache, %s instruction cache\n", ...)
> 
> In this case it's correct to add KERN_INFO to the last printk, isn't it?
> When would you consider it to be wrong?

I forgot about KERN_CONT, which did not exist until a few years ago
and is still not all that common. Initially, KERN_CONT was just an
empty string that was used to make it clear when a printk was
intentionally used as a continuation of the previous line, rather
than having no KERN_* at all.

In the example above, the first and the second line should get a KERN_INFO
or one of the others.

> If you want to have the first group of printks to always end in \n, I'd
> have to do:
> 
>                 printk("CPU: %s [%08x] revision %d (ARMv%s)", ...);
>         #ifdef CONFIG_CPU_CP15
>                 printk(KERN_CONT ", cr=%08lx", cr_alignment);
>         #endif
>                 printk(KERN_CONT "\n");
> 
> but ISTR Linus (Torvalds) telling me that KERN_CONT "\n" is wrong and
> should just be skipped.

Ok, didn't know that.

	Arnd