Linux kbuild/kconfig development
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Masahiro Yamada" <masahiroy@kernel.org>,
	"Heiko Carstens" <hca@linux.ibm.com>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Linux Kbuild mailing list" <linux-kbuild@vger.kernel.org>
Subject: Re: [GIT PULL] Kbuild updates for v6.16-rc1
Date: Wed, 11 Jun 2025 16:24:13 +0200	[thread overview]
Message-ID: <8992766a-cc96-40bb-b8c2-60931ad0f065@app.fastmail.com> (raw)
In-Reply-To: <CAK7LNASSeuZWAXS6tDGL1T8S1N9fmg4DND616BL6uco4gnYFqA@mail.gmail.com>

On Wed, Jun 11, 2025, at 15:32, Masahiro Yamada wrote:
> On Wed, Jun 11, 2025 at 4:55 PM Heiko Carstens <hca@linux.ibm.com> wrote:
>>
>> Don't get me wrong, I can address all of this trivial churn for s390, however
>> enforcing so many extra warnings to everyone with W=1 builds doesn't look like
>> the right approach to me.
>
> This is what W=1 is for.
> 0day bot detects a new W=1 warning, so we can avoid new warnings coming in.
>
> People do not know which headers should be included when.
> So, this warning must exist at least until we can get rid of
> #include <linux/export.h> from include/linux/module.h,
> include/linux/linkage.h etc.

I think this makes sense in general, but the output here is
excessive if it leads to users no longer wanting to enable W=1.

There are other warnings that I think should be enabled at the
W=1 level (e.g. -Wformat-security) and eventually by default,
but that are still too noisy at that level.

My own cutoff would be at a few hundred warnings in allmodconfig
builds if there is an effort to reduce it further, but it seems
that this one is still at a few thousand, which does not seem ok.

     Arnd

  reply	other threads:[~2025-06-11 14:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-07 16:41 [GIT PULL] Kbuild updates for v6.16-rc1 Masahiro Yamada
2025-06-07 19:07 ` pr-tracker-bot
2025-06-11  7:55 ` Heiko Carstens
2025-06-11 12:59   ` Sean Christopherson
2025-06-11 13:32   ` Masahiro Yamada
2025-06-11 14:24     ` Arnd Bergmann [this message]
2025-06-12  1:42       ` Masahiro Yamada
2025-06-12  8:01         ` Arnd Bergmann
2025-06-12 14:29           ` Heiko Carstens
2025-06-12 16:10             ` Masahiro Yamada
2025-06-12 15:39           ` Masahiro Yamada
2025-06-12  8:02         ` Heiko Carstens

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=8992766a-cc96-40bb-b8c2-60931ad0f065@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=hca@linux.ibm.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --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