From: Paolo Bonzini <pbonzini@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
KVM list <kvm@vger.kernel.org>, Oliver Upton <oupton@google.com>
Subject: Re: [GIT PULL] KVM changes for Linux 5.6-rc2
Date: Thu, 13 Feb 2020 08:14:11 +0100 [thread overview]
Message-ID: <d9f66725-993f-5434-5115-f173b36d52d7@redhat.com> (raw)
In-Reply-To: <CAHk-=wjv2V==7jGwg2OkyX4F6Cdtt4qCpdGF56rOi-kVtjGCZQ@mail.gmail.com>
On 12/02/20 21:13, Linus Torvalds wrote:
> On Wed, Feb 12, 2020 at 12:02 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> I know, but still I consider it. There is no reason why the "build
>> test" should be anything more than "make && echo yes i am build-tested".
>
> It damn well should check for warnings.
>
> And if you can't bother eye-balling it or scripting it, then simply use
>
> make KCFLAGS=-Werror
>
> but sadly I can't enforce that in general for all kernel builds simply
> because some people use compilers that cause new warnings (compiler
> updates etc commonly result in them, for example).
Shouldn't we _try_? Compilers are not adding or triggering as many
warnings as they were a few years ago, when clang came out or GCC 4
rewrote their middle end. Compiling the 10-year-old 2.6.32 these days
results in a couple warnings for the RHEL6 configuration. Sometimes
there are even hard errors making -Wno-error moot. We can fix them in
stable kernels. For master, distro people and build bots would catch
that early and we can fix everything quickly.
For the odd case such as a bisection on old trees, _that_ is when you
add -Wno-error. Special cases deserve special options, general cases
don't. The issue percolates all the way down to the developers, Oliver
could have specified KCFLAGS too and he wouldn't have sent the bad
patch, but honestly I can't blame him. You can blame me, :) but again
that doesn't mean Linux as a whole can't do better.
Anyway---sorry again for the screwup. I'll send a revised pull request
soon. Thanks,
Paolo
> So I can't add -Werror in general, but developers can certainly use it
> trivially.
>
> No grep or other scripting required (although the above may cause
> problems for that one sample file that does cause warnings - I didn't
> check).
>
> Linus
>
prev parent reply other threads:[~2020-02-13 7:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-12 16:47 Paolo Bonzini
2020-02-12 18:53 ` Linus Torvalds
2020-02-12 19:19 ` Paolo Bonzini
2020-02-12 19:38 ` Linus Torvalds
2020-02-12 19:53 ` Oliver Upton
2020-02-12 20:01 ` Paolo Bonzini
2020-02-12 20:13 ` Linus Torvalds
2020-02-13 7:14 ` Paolo Bonzini [this message]
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=d9f66725-993f-5434-5115-f173b36d52d7@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oupton@google.com \
--cc=torvalds@linux-foundation.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®