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

[Joe Perches <joe@perches.com>]

On Thu, 2010-10-28 at 10:43 +0200, Jean Delvare wrote:
> 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.

I think you underestimate the time, effort and acceptance
levels by the various arches and maintainers required.

Also, it's not just drivers, it's arch, lib, and kernel.

A short term issue might be .text expansion of embedded
platforms that use CONFIG_PRINTK.

It doesn't look as if too many people care though.