Re: [RFC] printk: More consistent loglevel for continuous lines

[Petr Mladek]

On Wed 2021-11-24 17:45:57, Joe Perches wrote:
> On Thu, 2021-11-25 at 09:53 +0900, Sergey Senozhatsky wrote:
> > On (21/11/24 16:48), Petr Mladek wrote:
> > > 
> > > Anyway, it looks a bit non-practical to update all existing pr_cont()
> > > callers:
> > > 
> > > 	$> git grep "pr_cont" | wc -l
> > > 	2054
> > 
> > Another question is how many pr_cont()-s are getting compiled with
> > the "average" production kernel config. A number of pr_cont() is in
> > debugging code - lockdep, kasan, etc. - which is not compiled for prod.
> 
> This was Linus' attempt to make KERN_CONT meaningful again when it
> was IMO a slightly different issue to fix bare printks.

Yes, the primary motivation for Linus' commit 4bcc595ccd80decb424
("printk: reinstate KERN_CONT for printing continuation lines) was
different. It solved the problem when two unrelated lines were
connected because of a missing newline.

The support for KERN_CONT together with real log level was just
a side effect because some code used it in the meantime.


> Linus changed the few bare printks that mattered to him at the time.

IMHO, Linus was more interested into the missing newlines. He did the
change in v4.9-rc1 and I see a lot of newlines fixes around.

Anyway, I checked v4.9 final sources and found only one location
that combined KERN_CONT with another real log level. It was

     pr_warn(KERN_CONT " trap #%lu: %s%c", code,

in arch/parisc/mm/fault.c. And it was later removed by the commit
commit 8351badf349b22b47c969 ("parisc: fix a printk").

I really can't find any occurrence of KERN_CONT together with
a real log level in the current sources.


We could make it required for new code by checkpatch.pl. But it would
still leave several hunderds/thousands of existing callers to be
fixed. And it seems that people do not care much about it.


Best Regards,
Petr