From: Jani Nikula <jani.nikula@intel.com>
To: Maxime Ripard <mripard@kernel.org>,
Nathan Chancellor <nathan@kernel.org>
Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
intel-xe@lists.freedesktop.org,
"David Airlie" <airlied@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>,
"Karol Herbst" <kherbst@redhat.com>,
"Lyude Paul" <lyude@redhat.com>,
"Danilo Krummrich" <dakr@redhat.com>,
"Rob Clark" <robdclark@gmail.com>,
"Abhinav Kumar" <quic_abhinavk@quicinc.com>,
"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
"Sean Paul" <sean@poorly.run>,
"Marijn Suijten" <marijn.suijten@somainline.org>,
"Hamza Mahfooz" <hamza.mahfooz@amd.com>,
"Javier Martinez Canillas" <javierm@redhat.com>,
"Sui Jingfeng" <sui.jingfeng@linux.dev>,
linux-kbuild@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [RESEND v3 2/2] drm: Add CONFIG_DRM_WERROR
Date: Wed, 27 Mar 2024 09:59:01 +0200 [thread overview]
Message-ID: <87a5mkgl6i.fsf@intel.com> (raw)
In-Reply-To: <20240327-cherubic-steel-tiger-e1c36a@houat>
On Wed, 27 Mar 2024, Maxime Ripard <mripard@kernel.org> wrote:
> Hi,
>
> On Tue, Mar 26, 2024 at 03:56:50PM -0700, Nathan Chancellor wrote:
>> On Tue, Mar 05, 2024 at 11:07:36AM +0200, Jani Nikula wrote:
>> > Add kconfig to enable -Werror subsystem wide. This is useful for
>> > development and CI to keep the subsystem warning free, while avoiding
>> > issues outside of the subsystem that kernel wide CONFIG_WERROR=y might
>> > hit.
>> >
>> > v2: Don't depend on COMPILE_TEST
>> >
>> > Reviewed-by: Hamza Mahfooz <hamza.mahfooz@amd.com> # v1
>> > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> > ---
>> > drivers/gpu/drm/Kconfig | 13 +++++++++++++
>> > drivers/gpu/drm/Makefile | 3 +++
>> > 2 files changed, 16 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> > index 6e853acf15da..c08e18108c2a 100644
>> > --- a/drivers/gpu/drm/Kconfig
>> > +++ b/drivers/gpu/drm/Kconfig
>> > @@ -416,3 +416,16 @@ config DRM_LIB_RANDOM
>> > config DRM_PRIVACY_SCREEN
>> > bool
>> > default n
>> > +
>> > +config DRM_WERROR
>> > + bool "Compile the drm subsystem with warnings as errors"
>> > + depends on EXPERT
>> > + default n
>> > + help
>> > + A kernel build should not cause any compiler warnings, and this
>> > + enables the '-Werror' flag to enforce that rule in the drm subsystem.
>> > +
>> > + The drm subsystem enables more warnings than the kernel default, so
>> > + this config option is disabled by default.
>> > +
>> > + If in doubt, say N.
>>
>> While I understand the desire for an easy switch that maintainers and
>> developers can use to ensure that their changes are warning free for the
>> drm subsystem specifically, I think subsystem specific configuration
>> options like this are actively detrimental to developers and continuous
>> integration systems that build test the entire kernel. For example, we
>> turned off CONFIG_WERROR for our Hexagon builds because of warnings that
>> appear with -Wextra that are legitimate but require treewide changes to
>> resolve in a manner sufficient for Linus:
>>
>> https://github.com/ClangBuiltLinux/linux/issues/1285
>> https://lore.kernel.org/all/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
>> https://lore.kernel.org/all/20230522105049.1467313-1-schnelle@linux.ibm.com/
>>
>> But now, due to CONFIG_DRM_WERROR getting enabled by all{mod,yes}config
>> and -Wextra being unconditionally enabled for DRM, those warnings hard
>> break the build despite CONFIG_WERROR=n...
>
> Would making DRM_WERROR depends on WERROR address your concerns?
But then what would be the point of having DRM_WERROR at all? For me the
point is, "werror in drm, ignore the rest, they're someone else's
problem".
An alternative would be to "depends on !COMPILE_TEST" that we have in
i915, but then some folks want to have COMPILE_TEST in drm, because some
drivers are otherwise hard for people to build.
Nathan, we do want to fix any issues switfly. Are you hitting specific
build problems?
BR,
Jani.
>
> Maxime
--
Jani Nikula, Intel
next prev parent reply other threads:[~2024-03-27 8:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-05 9:07 [RESEND v3 0/2] drm: enable W=1 warnings by default across the subsystem Jani Nikula
2024-03-05 9:07 ` [RESEND v3 1/2] drm: enable (most) " Jani Nikula
2024-05-17 21:04 ` Guenter Roeck
2024-03-05 9:07 ` [RESEND v3 2/2] drm: Add CONFIG_DRM_WERROR Jani Nikula
2024-03-05 10:14 ` Javier Martinez Canillas
2024-03-26 22:56 ` Nathan Chancellor
2024-03-27 7:34 ` Maxime Ripard
2024-03-27 7:59 ` Jani Nikula [this message]
2024-03-27 16:33 ` Nathan Chancellor
2024-03-28 11:33 ` Jani Nikula
2024-03-05 9:13 ` ✓ CI.Patch_applied: success for drm: enable W=1 warnings by default across the subsystem (rev2) Patchwork
2024-03-05 9:13 ` ✓ CI.checkpatch: " Patchwork
2024-03-05 9:14 ` ✓ CI.KUnit: " Patchwork
2024-03-05 9:32 ` ✓ CI.Build: " Patchwork
2024-03-05 9:32 ` ✓ CI.Hooks: " Patchwork
2024-03-05 9:34 ` ✗ CI.checksparse: warning " Patchwork
2024-03-05 10:15 ` ✓ CI.BAT: success " Patchwork
2024-03-05 11:29 ` [RESEND v3 0/2] drm: enable W=1 warnings by default across the subsystem Maxime Ripard
2024-03-05 17:43 ` Jani Nikula
2024-03-05 17:45 ` Lucas De Marchi
2024-03-05 17:50 ` Jani Nikula
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=87a5mkgl6i.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=Xinhui.Pan@amd.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=christian.koenig@amd.com \
--cc=dakr@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hamza.mahfooz@amd.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=javierm@redhat.com \
--cc=kherbst@redhat.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marijn.suijten@somainline.org \
--cc=mripard@kernel.org \
--cc=nathan@kernel.org \
--cc=quic_abhinavk@quicinc.com \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=sui.jingfeng@linux.dev \
--cc=tzimmermann@suse.de \
/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).