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

[Petr Mladek <pmladek@suse.com>]

On Thu 2021-11-25 09:53:49, 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.

It is still >500 for x86_64 default configuration as mentioned in
the reply by Joe.


> Let's assume something like this
> 
> 	foo()
> 	{
> 		char *s;
> 
> 		pr_cont("Blah ");
> 		s = arch_foo();
> 		pr_cont("%s \n", s);
> 	}
> 
> Suppose that arch_foo() errs and pr_warn()-s. Are we going to use WARN
> level for trailing pr_cont()?
> 
> 	pr_cont("Blah ") -> printk_write_loglevel_ctx(default)
> 	pr_warn() -> printk_write_loglevel_ctx(warn)
> 	pr_cont("%s \n"") <- printk_read_loglevel_ctx(warn)


Yes, the proposed solution will not work when there is a nested
message in the same context. It was even mentioned in the commit
message.

But nested messages break the continuous lines completely. They
primary break the text.

pr_cont()/KERN_CONT approach could work reasonably only for
self-contained code. Though even these lines might still get
interleaved by messages from another context/CPU. But it has
a solution. caller_id allows to connect the right pieces.
The proposed patch allows to preserve the loglevel and
actually see all the pieces.

pr_cont()/KERN_CONT is bad API for situations where the pieces
are printed by complicated and/or external code. Such code
should use its own buffer or avoid continuous lines at all.


By other words. The patch solves one fundamental problem when
pr_cont() is used reasonably. It does not help in situations
where pr_cont() should not be used at all.

Best Regards,
Petr