linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "John W. Linville" <linville@tuxdriver.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, Hauke Mehrtens <hauke@hauke-m.de>,
	"Luis R. Rodriguez" <lrodriguez@qca.qualcomm.com>
Subject: Re: [PATCH] compat-wireless: avoid pr_fmt build SPAM
Date: Fri, 18 Nov 2011 16:09:54 -0500	[thread overview]
Message-ID: <20111118210953.GC2663@tuxdriver.com> (raw)
In-Reply-To: <1321650012.10266.78.camel@jlt3.sipsolutions.net>

On Fri, Nov 18, 2011 at 10:00:12PM +0100, Johannes Berg wrote:
> On Fri, 2011-11-18 at 15:54 -0500, John W. Linville wrote:
> > The way the compat-* header files are included causes the default
> > pr_fmt definition from <linux/kernel.h> to be evaluated for every file.
> > Files that define pr_fmt then generate a lot of build SPAM about
> > pr_fmt being redefined.
> > 
> > Eliminate the build noise by preemptively undefining pr_fmt in those
> > files that define it.  This is accomplished by adding a patch to the
> > patches directory.
> 
> This patch is going to be relatively painful when files move etc -- is
> that really worth it? I for one will just drop it in our compat version
> if it goes in since I don't even have all the files it patches :-)

I don't know how much those definitions will move, since they are
rooted to the tops of those files anyway.  If the files move or
whatever there will be some flux.  But then you'll be no worse-off
than we are now for that file, and hopefully only a few hunks will
have problems at any given time.

Personally, I hate seeing all those warnings fly-by.  It is even worse
when you know you are building backported code, where my experience
suggests that warnings are more likely to be revealing real problems.
Having all that SPAM about pr_fmt being redefined is just encouraging
us to ignore what might otherwise be legitimate warnings.

These hunks are one-liners that I predict will change rarely and
which are obvious to move or to add to new files.  I'd rather have
this patch than not.

John

P.S.  I'll see your threat to drop the patch at Intel and I'll raise
it with my threat to add the patch to Fedora. :-)
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

  reply	other threads:[~2011-11-18 21:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-18 20:54 [PATCH] compat-wireless: avoid pr_fmt build SPAM John W. Linville
2011-11-18 21:00 ` Johannes Berg
2011-11-18 21:09   ` John W. Linville [this message]
2011-11-18 21:12   ` Luis R. Rodriguez
2011-11-18 21:49     ` John W. Linville
2011-11-18 22:26 ` Joe Perches
2011-11-18 22:34   ` John W. Linville
2011-11-18 23:03     ` Luis R. Rodriguez
2011-11-18 23:21       ` Hauke Mehrtens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111118210953.GC2663@tuxdriver.com \
    --to=linville@tuxdriver.com \
    --cc=hauke@hauke-m.de \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lrodriguez@qca.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).