Messages in this thread | | | Date | Mon, 6 Dec 2021 18:34:14 +0100 | From | Petr Mladek <> | Subject | Re: [RFC] printk: More consistent loglevel for continuous lines |
| |
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
| |