[PATCH v3 2/5] ARM: Add a printk loglevel modifier
Arnd Bergmann
arnd at arndb.de
Wed Mar 14 17:40:54 EDT 2012
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
More information about the linux-arm-kernel
mailing list