[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiin_LkqP2Cm5iPc5snUXYqZVoMFawZ-rjhZnawven8SA@mail.gmail.com>
Date: Sun, 1 Mar 2020 15:33:48 -0600
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Paolo Bonzini <pbonzini@...hat.com>,
Michael Ellerman <mpe@...erman.id.au>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
KVM list <kvm@...r.kernel.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5)
On Sun, Mar 1, 2020 at 1:03 PM Paolo Bonzini <pbonzini@...hat.com> wrote:
>
> Paolo Bonzini (4):
> KVM: allow disabling -Werror
Honestly, this is just badly done.
You've basically made it enable -Werror only for very random
configurations - and apparently the one you test.
Doing things like COMPILE_TEST disables it, but so does not having
EXPERT enabled.
So it looks entirely ad-hoc and makes very little sense. At least the
"with KASAN, disable this" part makes sense, since that's a known
source or warnings. But everything else looks very random.
I've merged this, but I wonder why you couldn't just do what I
suggested originally?
Seriously, if you script your build tests, and don't even look at the
results, then you might as well use
make KCFLAGS=-Werror
instead of having this kind of completely random option that has
almost no logic to it at all.
And if you depend entirely on random build infrastructure like the
0day bot etc, this likely _is_ going to break when it starts using a
new gcc version, or when it starts testing using clang, or whatever.
So then we end up with another odd random situation where now kvm (and
only kvm) will fail those builds just because they are automated.
Yes, as I said in that original thread, I'd love to do -Werror in
general, at which point it wouldn't be some random ad-hoc kvm special
case for some random option. But the "now it causes problems for
random compiler versions" is a real issue again - but at least it
wouldn't be a random kernel subsystem that happens to trigger it, it
would be a _generic_ issue, and we'd have everybody involved when a
compiler change introduces a new warning.
I've pulled this for now, but I really think it's a horrible hack, and
it's just done entirely wrong.
Adding the powerpc people, since they have more history with their
somewhat less hacky one. Except that one automatically gets disabled
by "make allmodconfig" and friends, which is also kind of pointless.
Michael, what tends to be the triggers for people using
PPC_DISABLE_WERROR? Do you have reports for it? Could we have a
_generic_ option that just gets enabled by default, except it gets
disabled by _known_ issues (like KASAN).
Being disabled for "make allmodconfig" is kind of against one of the
_points_ of "the build should be warning-free".
Linus
Powered by blists - more mailing lists