linux-kernel - Re: [RFC] Remove most all #define pr

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] [day] [month] [year] [list]

Message-ID: <20120328163354.GA3232@opensource.wolfsonmicro.com>
Date:	Wed, 28 Mar 2012 17:33:55 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Joe Perches <joe@...ches.com>
Cc:	Clemens Ladisch <clemens@...isch.de>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jason Baron <jbaron@...hat.com>,
	Jim Cromie <jim.cromie@...il.com>, Liam Girdwood <lrg@...com>
Subject: Re: [RFC] Remove most all #define pr_fmt(fmt) lines

On Wed, Mar 28, 2012 at 09:22:45AM -0700, Joe Perches wrote:
> On Wed, 2012-03-28 at 10:46 +0100, Mark Brown wrote:

Please at least leave the blank lines others put in their mails when
quoting even if you don't add any between paragraphs yourself, it really
makes things much more legible.

> > > > Instead of doing a Makefile change that has no _obvious_ connection with
> > > > printk, wouldn't it be better to just define pr_fmt with "regulator: "?

> > This seems like a much better idea if we're going to do anything; it
> > means that we don't end up embedding module names in things (which are
> > after all a bit of an implementation detail) and get to pick the name so
> > we can do something like get the prefix which is used for the symbols in
> > the code even if things are split over multiple modules.

> A negative is that requires #defines in multiple
> source files or rearranging #includes to centralize
> that #define.

You only need to do this in cases where the module name isn't a good
choice which hopefully should be relatively rare, and I'd expect a lot
of the time things will be in one source file anyway (as with the
regulator case).

> A negative of the Makefile approach is the name is
> obscurely chosen.  A positive is it's only chosen
> once.

I don't think this is an either/or thing - you can default to using the
module name and override it where needed which like I say should
hopefully be relatively rare (though the sound tree will probably need
to do this pretty much everywhere due to the naming convention it uses).

> > In the case above we don't support modular build in the first place.

> Unrelated but is there any particular reason why
> the regulator core code couldn't be build as a
> module?

It's not worth bothering, it's needed spectacularly early on in most
practical systems (including by board files that are always built in as
bits of them run prior to I/O mappings and whatnot being set up).  The
main practical result would be lots more hassle with dependencies in
Kconfig so the randconfig folks can do their stuff and no change in
actual configurations that people deploy.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)