From: Jakub Kicinski <kuba@kernel.org>
To: Jani Nikula <jani.nikula@intel.com>
Cc: Sean Christopherson <seanjc@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
pbonzini@redhat.com, workflows@vger.kernel.org,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: deprecate KVM_WERROR in favor of general WERROR
Date: Tue, 10 Oct 2023 07:23:59 -0700 [thread overview]
Message-ID: <20231010072359.0df918e9@kernel.org> (raw)
In-Reply-To: <87sf6i6gzh.fsf@intel.com>
On Tue, 10 Oct 2023 11:04:18 +0300 Jani Nikula wrote:
> > If you do invest in build testing automation, why can't your automation
> > count warnings rather than depend on WERROR? I don't understand.
>
> Because having both CI and the subsystem/driver developers enable a
> local WERROR actually works in keeping the subsystem/driver clean of
> warnings.
>
> For i915, we also enable W=1 warnings and kernel-doc -Werror with it,
> keeping all of them warning clean. I don't much appreciate calling that
> anti-social.
Anti-social is not the right word, that's fair.
Werror makes your life easier while increasing the blast radius
of your mistakes. So you're trading off your convenience for risk
of breakage to others. Note that you can fix issues locally very
quickly and move on. Others have to wait to get your patches thru
Linus.
> >> I disagree. WERROR simply doesn't provide the same coverage. E.g. it can't be
> >> enabled for i386 without tuning FRAME_WARN, which (a) won't be at all obvious to
> >> the average contributor and (b) increasing FRAME_WARN effectively reduces the
> >> test coverage of KVM i386.
> >>
> >> For KVM x86, I want the rules for contributing to be clearly documented, and as
> >> simple as possible. I don't see a sane way to achieve that with WERROR=y.
>
> The DRM_I915_WERROR config depends on EXPERT and !COMPILE_TEST, and to
> my knowledge this has never caused issues outside of i915 developers and
> CI.
Ack, I think you do it right. I was trying to establish a precedent
so that we can delete these as soon as they cause an issue, not sooner.
Whatever tho, there's no accounting for taste.
next prev parent reply other threads:[~2023-10-10 14:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-06 20:54 Jakub Kicinski
2023-10-09 17:18 ` Kees Cook
2023-10-09 17:43 ` Sean Christopherson
2023-10-09 18:06 ` Jakub Kicinski
2023-10-09 19:33 ` Sean Christopherson
2023-10-09 21:49 ` Jakub Kicinski
2023-10-10 8:04 ` Jani Nikula
2023-10-10 14:23 ` Jakub Kicinski [this message]
2023-10-10 23:46 ` Sean Christopherson
2023-10-12 15:17 ` Paolo Bonzini
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=20231010072359.0df918e9@kernel.org \
--to=kuba@kernel.org \
--cc=jani.nikula@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=torvalds@linux-foundation.org \
--cc=workflows@vger.kernel.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