Re: [PATCH v2] debugobjects: Move printk out of db lock critical sections

From: Ingo Molnar
Date: Tue Dec 18 2018 - 08:52:04 EST

* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Mon, Dec 17, 2018 at 10:17 AM Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> >
> > We should rename printk() to syslog() or so, and rename early_printk() to
> > printk(), and be done with this.
> No.
> As already pointed out, the syslog part isn't the issue. The printing
> part is the issue.

Indeed - I fired a shot fired in the wrong direction ...

> So thinking that early_printk is any better is just puting your head in
> the sand.

... at my own feet. ;-) Apologies to the syslog folks!

early_printk should still in principle be more robust: it tries to use as
little (no) locking as possible, and definitely tries to do no
allocations. It doesn't use syslog, nor any console locking, nor any
regular console drivers.

Which results in usability trade-offs: trashed screen output, mangled
lines. It's a superior debug facility when debugging particularly hairy
low level code - which most of the kernel isn't where it turns into an
inferior debugging method.

I thing a good solution would be PeterZ's force_early_printk boot knob,
for those low level folks who absolutely want to rely on printk always
working in some fashion.

( I think it might even be possible to add a non-locked feature to
early-printk that actually adds the messages to the syslog ring-buffer
- without any notification/wakeup/serialization features. 'dmesg' is
handy and its lack is the primary usability disadvantage of
earlyprintk. )