From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Rustad, Mark D" <mark.d.rustad@intel.com>,
"sparse@chrisli.org" <sparse@chrisli.org>,
"linux-sparse@vger.kernel.org" <linux-sparse@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/7] Silence even more W=2 warnings
Date: Mon, 22 Sep 2014 14:21:52 -0700 [thread overview]
Message-ID: <1411420912.2513.32.camel@jtkirshe-mobl.jf.intel.com> (raw)
In-Reply-To: <20140922203336.GF4709@pd.tnic>
[-- Attachment #1: Type: text/plain, Size: 3310 bytes --]
On Mon, 2014-09-22 at 22:33 +0200, Borislav Petkov wrote:
> On Mon, Sep 22, 2014 at 01:09:33PM -0700, Jeff Kirsher wrote:
> > Sorry I am very frustrated at your response.
>
> You shouldn't be. Judging by your reply below it seems we do actually
> agree... mostly :-)
>
> > I am not saying that the proposed added MACRO is the best solution to
> > this issue. Several other maintainers have actually responded in a
> > similar manner to the macros being added and came back that the better
> > solution would be to fix the code so that the warnings do not occur in
> > the first place.
>
> Right, this would be optimal.
>
> > So I guess I was hoping for more of the response, that "let's fix this
> > the code so that the warnings do not appear in the first place".
> >
> > I agree with you completely that I do not like the idea of the MACROS
> > being added to silence these warnings. I just disagree that not doing
> > anything to fix the warnings is far worse.
>
> Ok, good, so we're on the same page here.
>
> > Why grep through 100,000 warnings, when we should be fixing the code to
> > prevent 100,000 warnings. Not saying that the MACRO is the best
> > solution, it is just a solution, in hopes that it spurs discussions like
> > this on how to properly fix the warnings. Not a discussion on how to
> > grep through the warnings and do nothing.
>
> There's only one thing I don't understand: why is so bad to grep through
> the warnings? I mean, sure, fixing them *without* jumping through hoops
> to do so is the optimal thing. But what's wrong with grepping through
> them?
Nothing is wrong with grepping for an error, especially when you know
the error your grepping for. But then again, why grep when it can be
fixed to begin with? The fact that there are over 100,000
warnings/errors to begin with is somewhat disconcerting. It makes me
wonder whether it was due to coding laziness.
>
> Btw, out of curiosity, what is your use case for staring at those W=2
> warnings?
To make a better (more solid) network driver? Mark has found it useful
to do the W= builds. For me personally, I do not bother because there
are over 100,000 warnings and it takes forever to get through a build
and then grep for our drivers to see if they are generating any
warnings.
>
> In thinking about it, what we could also do is simply move the noisiest
> ones to W=3 or so, or even add another W= level. It'll be interesting to
> hear your use case though. AFAICT, this is the first time I hear of a
> more, let's say, serious use case of W= since we added the W= things a
> couple of years ago. :-)
>
I could see this useful if there is no way to fix the issue that really
is not an issue and the compiler just does not know any better, but this
concerns me that we would get into a bad habit. "Oh I really do not
want to fix this, so I will just make it so that people we not have to
see this warning/error" Again, sounds lazy to me, of course I am just
speaking in a generalization. I am sure that some of the warnings will
fall into the category of, it needs to be silenced and not fixed because
the fix is far more troublesome. I just cannot believe that most or all
the warnings would be that way.
> Thanks.
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-09-22 21:22 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-19 15:29 [PATCH 0/7] Silence even more W=2 warnings Jeff Kirsher
2014-09-19 15:29 ` [PATCH 1/7] compiler: Add diagnostic control macros Jeff Kirsher
2014-09-19 15:29 ` [PATCH 2/7] x86: Silence initializer-overrides warnings Jeff Kirsher
2014-09-19 15:29 ` [PATCH 3/7] atomic: Silence nested-externs warnings Jeff Kirsher
2014-09-19 20:43 ` Peter Zijlstra
2014-09-19 20:53 ` Jeff Kirsher
2014-09-19 15:29 ` [PATCH 4/7] bitops: " Jeff Kirsher
2014-09-19 15:29 ` [PATCH 5/7] signal: " Jeff Kirsher
2014-09-19 15:35 ` Richard Weinberger
2014-09-19 15:37 ` Jeff Kirsher
2014-09-19 15:39 ` Richard Weinberger
2014-09-19 17:20 ` Oleg Nesterov
2014-09-19 21:21 ` Josh Triplett
2014-09-19 21:26 ` Rustad, Mark D
2014-09-21 16:42 ` [PATCH 0/1] signal: use BUILD_BUG() instead of _NSIG_WORDS_is_unsupported_size() Oleg Nesterov
2014-09-21 16:43 ` [PATCH 1/1] " Oleg Nesterov
2014-09-22 17:26 ` Josh Triplett
2014-09-19 15:29 ` [PATCH 6/7] mm: Silence nested-externs warnings Jeff Kirsher
2014-09-19 15:29 ` [PATCH 7/7] sched: " Jeff Kirsher
2014-09-19 19:34 ` Richard Weinberger
2014-09-19 20:34 ` Rustad, Mark D
2014-09-19 20:41 ` Richard Weinberger
2014-09-19 20:49 ` Rustad, Mark D
2014-09-22 17:55 ` [PATCH] sched: Remove nested extern Mark D Rustad
2014-09-22 18:25 ` Josh Triplett
2014-09-22 19:01 ` Peter Zijlstra
2014-09-22 19:32 ` Rustad, Mark D
2014-09-22 20:05 ` Peter Zijlstra
2014-09-22 20:59 ` Rustad, Mark D
2014-09-22 21:21 ` Peter Zijlstra
2014-09-22 21:50 ` Rustad, Mark D
2014-09-24 7:41 ` Ingo Molnar
2014-09-24 7:52 ` Peter Zijlstra
2014-09-24 7:58 ` Ingo Molnar
2014-09-19 22:54 ` [PATCH 7/7] sched: Silence nested-externs warnings Peter Zijlstra
2014-09-19 23:26 ` Rustad, Mark D
2014-09-22 15:33 ` [PATCH 0/7] Silence even more W=2 warnings Borislav Petkov
2014-09-22 17:06 ` Rustad, Mark D
2014-09-22 18:40 ` Borislav Petkov
2014-09-22 18:59 ` Rustad, Mark D
2014-09-22 19:21 ` Borislav Petkov
2014-09-22 19:44 ` Jeff Kirsher
2014-09-22 19:57 ` Borislav Petkov
2014-09-22 20:09 ` Jeff Kirsher
2014-09-22 20:33 ` Borislav Petkov
2014-09-22 21:21 ` Jeff Kirsher [this message]
2014-09-23 8:01 ` Borislav Petkov
2014-09-23 14:49 ` Josh Triplett
2014-09-23 16:08 ` Borislav Petkov
2014-09-23 16:29 ` Rustad, Mark D
2014-09-25 7:45 ` Geert Uytterhoeven
2014-09-25 16:44 ` Borislav Petkov
2014-09-26 19:37 ` Rustad, Mark D
2014-09-26 19:58 ` josh
2014-09-26 21:07 ` Rustad, Mark D
2014-09-22 21:50 ` Rustad, Mark D
2014-09-23 8:22 ` Borislav Petkov
2014-09-23 17:24 ` Rustad, Mark D
2014-09-23 18:44 ` Borislav Petkov
2014-09-23 19:04 ` Joe Perches
2014-09-23 20:43 ` Rustad, Mark D
2014-09-25 8:27 ` Borislav Petkov
2014-09-25 0:17 ` Rustad, Mark D
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=1411420912.2513.32.camel@jtkirshe-mobl.jf.intel.com \
--to=jeffrey.t.kirsher@intel.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=mark.d.rustad@intel.com \
--cc=sparse@chrisli.org \
/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).