From: Jean Delvare <khali@linux-fr.org>
To: Joe Perches <joe@perches.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Guenter Roeck <guenter.roeck@ericsson.com>
Subject: Re: [RFC PATCH] include/linux/kernel.h: Add config option for pr_fmt(fmt)
Date: Thu, 28 Oct 2010 09:35:29 +0200 [thread overview]
Message-ID: <20101028093529.503c3a28@endymion.delvare> (raw)
In-Reply-To: <1288201301.4145.122.camel@Joe-Laptop>
On Wed, 27 Oct 2010 10:41:41 -0700, Joe Perches wrote:
> On Tue, 2010-10-26 at 11:03 +0200, Jean Delvare wrote:
> > On Thu, 21 Oct 2010 19:19:42 -0700, Joe Perches wrote:
> > > Change the default #define pr_fmt(fmt) from:
> > > - #define pr_fmt(fmt) fmt
> > > to:
> > > - #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > This will standard use of prefixes and prevent the
> > > addition of new #defines when using pr_<level>.
> > I'm all for it!
> > > Adds a config option to use the old style if desired.
> > Not sure what the idea is. Once pr_fmt() includes the module name, we
> > will drop hard-coded prefixes in all log messages throughout the kernel
> > tree. Once this is done, a kernel built with PR_FMT_IS_KBUILD_MODNAME=n
> > would become horribly confusing.
>
> True. The idea is to allow a transition period and remove
> this PR_FMT_IS_KBUILD_MODNAME config option later.
I don't buy this, sorry. During the "transition period", neither value
of this option will produce good results. One will lead to duplicate
prefixes and the other will lead to missing prefixes.
I think it's preferable to drop this option, and prepare patches for
all drivers, so that the change happens all at once and we're done with
it. You seem to have all the tools to produce such patches, right?
Of course there will be 1% of all messages which we won't get right,
and they will have t be fixed afterwards, but I don't think this is a
problem.
> > How relevant is the x86 defconfig?
> > It doesn't include any hardware-specific driver, does it?
>
> It adds lots of x86 specific drivers...
>
> > I've used the following grep to find them: grep -I 'pr_[a-z]*([^"]'
> > Let me know if you have anything better.
>
> Perhaps use -P
> "\bpr_(emerg|alert|crit|err|warning|warn|notice|info|cont|debug)\s*\(\s*\"\w+:"
Ah, right. This finds the hard-coded prefixes, my approach only caught
the constant prefixes. So we want to run both.
> Another way is to use:
> strings <vmlinux|other> | grep -P "^<.>\w+:"
This catches everything, but you don't always know where the string
comes from, so it isn't as convenient.
--
Jean Delvare
next prev parent reply other threads:[~2010-10-28 7:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-22 2:19 Joe Perches
[not found] ` <alpine.LFD.2.00.1010220131320.7016@localhost.localdomain>
2010-10-22 22:23 ` [PATCH] drivers/acpi: Add and use pr_fmt(fmt) Joe Perches
2010-10-26 9:03 ` [RFC PATCH] include/linux/kernel.h: Add config option for pr_fmt(fmt) Jean Delvare
2010-10-27 17:41 ` Joe Perches
2010-10-28 4:28 ` Guenter Roeck
2010-10-28 7:35 ` Jean Delvare [this message]
2010-10-28 7:54 ` Joe Perches
2010-10-28 8:43 ` Jean Delvare
2010-10-29 22:10 ` Joe Perches
2010-11-08 12:33 ` Jean Delvare
2010-11-08 16:55 ` Guenter Roeck
2010-11-08 17:16 ` Joe Perches
2010-11-09 3:07 ` Guenter Roeck
2010-11-09 8:42 ` Jean Delvare
2010-11-09 16:16 ` Guenter Roeck
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=20101028093529.503c3a28@endymion.delvare \
--to=khali@linux-fr.org \
--cc=akpm@linux-foundation.org \
--cc=guenter.roeck@ericsson.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
/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
Powered by JetHome