mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rustad, Mark D" <mark.d.rustad@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@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 17:06:27 +0000	[thread overview]
Message-ID: <AEF1C0F7-239C-436B-97A5-6AFF49FD9359@intel.com> (raw)
In-Reply-To: <20140922153355.GB4510@pd.tnic>

[-- Attachment #1: Type: text/plain, Size: 2703 bytes --]

On Sep 22, 2014, at 8:33 AM, Borislav Petkov <bp@alien8.de> wrote:

> On Fri, Sep 19, 2014 at 08:29:33AM -0700, Jeff Kirsher wrote:
>> The following patches silence over 100,000 warnings in a W=2
>> kernel build. This series does most of it by using the compilers
>> diagnostic controls. The first patch in the series adds macros to
>> invoke the pragmas for those controls. Macros are provided for GCC
>> and clang. Although they are highly compatible in this area, macros
>> are provided for compiler-specific controls, and there is one
>> example that uses a clang-specific control (look for DIAG_CLANG_IGNORE).
>> 
>> Some missing-field-initializers warnings were resolved using
>> the diagnostic control macros simply because so many lines
>> would have had to have been changed. At this stage Mark thought 
>> about avoiding possible merge issues. If the maintainer would 
>> rather resolve them by using designated initialization, just 
>> say so.
>> 
>> The combined effect of this patch series and his other patches
>> that did not use these diagnostic control macros was to reduce 
>> the number of W=2 warnings from 127,164 to 1,345!
> 
> Sorry but I don't see the point of actively adding macros to the code
> just so that gcc is happy. There's a reason why a bunch of warnings are
> disabled in the normal build and only enabled with the W= switch.
> 
> The W= things are supposed to be used when developing code and have the
> compiler tell you about *possible* issues. That doesn't mean though that
> we have to actively "fix" otherwise perfectly fine code.

The problem is that the kernel include files throw so many warnings that it really discourages anyone from ever going through them, even for a single driver. The warnings are far more valuable and usable when known acceptable usages are silenced.

> Having the need to actively go in and add code so that gcc doesn't issue
> obscure warnings is going too far, IMO.

Well, the whole series of patches that I made definitely went too far - only the first 5 out of about 30 have been posted, but if we can make some progress on generating fewer warnings out of the include files, I think it would be helpful. Already the patches that use them have triggered some activity that has resulted in resolving warnings without use of the macros, and I see that as much better than simply using the macros.

The macros can serve a useful purpose, but they should not be widely used. When to use them is definitely a judgement call. If the macros are accepted, it may be worth adding a checkpatch.pl warning for adding a DIAG_*IGNORE macro.

-- 
Mark Rustad, Networking Division, Intel Corporation


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

  reply	other threads:[~2014-09-22 17:07 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-19 15:29 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 [this message]
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
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=AEF1C0F7-239C-436B-97A5-6AFF49FD9359@intel.com \
    --to=mark.d.rustad@intel.com \
    --cc=bp@alien8.de \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®