Re: [RFC PATCH] include/linux/kernel.h: Add config option for pr_fmt(fmt)

[Jean Delvare <khali@linux-fr.org>]

On Thu, 28 Oct 2010 00:54:36 -0700, Joe Perches wrote:
> On Thu, 2010-10-28 at 09:35 +0200, Jean Delvare wrote:
> > 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.
> 
> So why don't you change it in your kernel.h and include that
> in linux-next and see how many complaints you get.

It would seem awkward that the i2c or hwmon tree would touch kernel.h.

Besides, linux-next is meant for integration testing. We already know
that the change will integrate fine, in that it won't cause a build
failure or runtime crash. We also know that, without the tree-wide
cleanup of many driver, the change will cause duplicate prefixes in
many messages.

There's little point in testing something we know will not be good
enough. Better prepare all the driver patches, and test the whole thing
when it's ready. I know it will be a very large and intrusive patchset,
but this can certainly be done with Andrew's support.

-- 
Jean Delvare