From: Borislav Petkov <bp@alien8.de>
To: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
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 21:57:37 +0200 [thread overview]
Message-ID: <20140922195737.GE4709@pd.tnic> (raw)
In-Reply-To: <1411415057.2513.8.camel@jtkirshe-mobl.jf.intel.com>
On Mon, Sep 22, 2014 at 12:44:17PM -0700, Jeff Kirsher wrote:
> Not sure you showed us, since that is how everyone has had to do to
> actual find W= builds useful. Just because that is how we HAVE to do it
> now, does not make it the best way. Here is a thought, we don't we fix
> the potential issues, so that W= builds do not generate over 100,000
> errors/warnings.
>
> Mark did this approach because it would either spur the conversation
> that this is a good idea OR let's fix the root problem. Instead it
> sounds like your response is "life sucks, get over it" and put your head
> back in the sand to ignore the problem.
Hey hey, relax a little - no need to get offensive all of a sudden.
Having to grep through a log file full of gcc warnings is a much better
thing to do IMNSVHO than adding code to the kernel just to shut up the
compiler. We had huge discussions even about something as silly as
uninitialized_var() which was supposed to shut up the compiler but ended
up actively causing bugs.
Now, you're arguing for adding obscure macros to shut up warnings which
are disabled in the first place because you don't want to grep through
log files.
If you can't see the absurdity of your proposal then maybe we should
agree to disagree and declare this back-and-forth for having run its
course. In any case, you get my NAK for it.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2014-09-22 19:57 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 [this message]
2014-09-22 20:09 ` Jeff Kirsher
2014-09-22 20:33 ` Borislav Petkov
2014-09-22 21:21 ` Jeff Kirsher
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=20140922195737.GE4709@pd.tnic \
--to=bp@alien8.de \
--cc=jeffrey.t.kirsher@intel.com \
--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).