[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101028093529.503c3a28@endymion.delvare>
Date: Thu, 28 Oct 2010 09:35:29 +0200
From: Jean Delvare <khali@...ux-fr.org>
To: Joe Perches <joe@...ches.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Guenter Roeck <guenter.roeck@...csson.com>
Subject: Re: [RFC PATCH] include/linux/kernel.h: Add config option for
pr_fmt(fmt)
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists