lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ