From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
yang.shi@linux.alibaba.com, Arnd Bergmann <arnd@arndb.de>,
sergey.senozhatsky.work@gmail.com, dima@arista.com, bp@alien8.de
Subject: Re: [PATCH v2] debugobjects: Move printk out of db lock critical sections
Date: Tue, 18 Dec 2018 14:51:53 +0100 [thread overview]
Message-ID: <20181218135153.GA101957@gmail.com> (raw)
In-Reply-To: <CAHk-=wjhqBYmzOyg7LPjvZhoXr3Tr+k9+caG2ScdCtZeO6oJcQ@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, Dec 17, 2018 at 10:17 AM Ingo Molnar <mingo@kernel.org> 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. )
Thanks,
Ingo
next prev parent reply other threads:[~2018-12-18 13:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 21:59 [PATCH v2] debugobjects: Move printk out of db lock critical sections Waiman Long
2018-12-17 18:17 ` Ingo Molnar
2018-12-17 18:33 ` Waiman Long
2018-12-17 19:31 ` Peter Zijlstra
2018-12-17 19:44 ` Linus Torvalds
2018-12-18 13:51 ` Ingo Molnar [this message]
2018-12-18 14:06 ` Thomas Gleixner
2018-12-18 2:23 ` Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181218135153.GA101957@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dima@arista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=peterz@infradead.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=yang.shi@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox