All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Chris Down <chris@chrisdown.name>,
	linux-kernel@vger.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	John Ogness <john.ogness@linutronix.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Kees Cook <keescook@chromium.org>,
	kernel-team@fb.com
Subject: Re: [PATCH v5] printk: Userspace format enumeration support
Date: Mon, 19 Apr 2021 11:53:37 +0200	[thread overview]
Message-ID: <YH1TIebAQyiMPuvI@kroah.com> (raw)
In-Reply-To: <YH1Kex8NOr89BJXq@alley>

On Mon, Apr 19, 2021 at 11:16:43AM +0200, Petr Mladek wrote:
> On Mon 2021-04-19 09:27:43, Rasmus Villemoes wrote:
> > On 16/04/2021 15.56, Chris Down wrote:
> > > Hey Petr, Rasmus,
> > 
> > >> This is great point! There are many other subsystem specific wrappers,
> > >> e,g, ata_dev_printk(), netdev_printk(), snd_printk(), dprintk().
> > >> We should make it easy to index them as well.
> > > 
> > > These would be nice to have, but we should agree about how we store
> > > things internally.
> > > 
> > > For example, in printk we typically store the level inline as part of
> > > the format string at compile time. However, for `dev_printk`, it's
> > > passed entirely separately from the format string after preprocessing is
> > > already concluded (or at least, not in a way we can easily parse it the
> > > same way we do for printk()):
> > > 
> > >     void dev_printk(const char *level, const struct device *dev, const
> > > char *fmt, ...)
> > 
> > Hm, yeah, for "naked" dev_printk() calls there's no easy way to grab the
> > level, for dev_err and friends it's somewhat easier as you could just
> > hook into the definition of the dev_err macro. I'm not saying you need
> > to handle everything at once, but doing dev_err and netdev_err would get
> > you a very long way
> 
> It is true that there are many messages printed using
> dev_printk(). For example, these rough numbers:
> 
> $> git grep pr_err | wc -l
> 19885
> $> git grep dev_err | wc -l
> 58153

You need "-w" :)

And I bet most of those pr_err() should be turned into dev_err(), if
they live in drivers/.

Hm, 12734 of the pr_err() calls do live in drivers/, so most of those
should be dev_err().  Might be something good to throw at interns...

thanks,

greg k-h

  reply	other threads:[~2021-04-19  9:53 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10  2:30 [PATCH v5] printk: Userspace format enumeration support Chris Down
2021-03-10  6:20 ` kernel test robot
2021-03-10  6:20   ` kernel test robot
2021-03-10  6:50 ` Greg Kroah-Hartman
2021-03-10 12:12   ` Chris Down
2021-03-10 12:16     ` Greg Kroah-Hartman
2021-03-11  9:34       ` Petr Mladek
2021-03-11  9:43         ` Greg Kroah-Hartman
2021-03-10 12:17 ` Chris Down
2021-03-11  9:20   ` Petr Mladek
2021-03-10 12:31 ` kernel test robot
2021-03-10 12:31   ` kernel test robot
2021-03-12 11:14 ` Petr Mladek
2021-03-12 13:53   ` Chris Down
2021-03-15 10:02     ` Petr Mladek
2021-03-15 12:20       ` Chris Down
2021-03-16 11:39         ` Petr Mladek
2021-03-16 13:27           ` Chris Down
2021-03-16 14:12 ` Rasmus Villemoes
2021-03-16 14:28   ` Chris Down
2021-03-17  8:40     ` Petr Mladek
2021-03-17 10:03       ` Rasmus Villemoes
2021-03-18 10:46         ` Petr Mladek
2021-03-18 11:31           ` Rasmus Villemoes
2021-03-19 11:43             ` Petr Mladek
2021-04-16 13:56           ` Chris Down
2021-04-16 14:09             ` Joe Perches
2021-04-16 14:29               ` Chris Down
2021-04-19  7:27             ` Rasmus Villemoes
2021-04-19  9:16               ` Petr Mladek
2021-04-19  9:53                 ` Greg Kroah-Hartman [this message]
2021-04-19 11:02                   ` Joe Perches
2021-04-21 13:14               ` Chris Down
2021-04-22 12:36                 ` Joe Perches
2021-04-22 14:59                   ` Chris Down

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=YH1TIebAQyiMPuvI@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=chris@chrisdown.name \
    --cc=hannes@cmpxchg.org \
    --cc=john.ogness@linutronix.de \
    --cc=keescook@chromium.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.