All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, David Airlie <airlied@gmail.com>,
	Simona Vetter <simona.vetter@ffwll.ch>,
	linux-kbuild@vger.kernel.org, dri-devel@lists.freedesktop.org,
	intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 0/4] kbuild: resurrect generic header check facility
Date: Tue, 8 Apr 2025 13:01:27 -0300	[thread overview]
Message-ID: <20250408160127.GD1778492@nvidia.com> (raw)
In-Reply-To: <871pu3ys4x.fsf@intel.com>

On Tue, Apr 08, 2025 at 11:27:58AM +0300, Jani Nikula wrote:
> On Mon, 07 Apr 2025, Jason Gunthorpe <jgg@nvidia.com> wrote:
> > On Mon, Apr 07, 2025 at 10:17:40AM +0300, Jani Nikula wrote:
> >
> >> Even with Jason's idea [1], you *still* have to start small and opt-in
> >> (i.e. the patch series at hand). You can't just start off by testing
> >> every header in one go, because it's a flag day switch. 
> >
> > You'd add something like 'make header_check' that does not run
> > automatically. Making it run automatically after everything is fixed
> > to keep it fixed would be the flag day change. It is how we have
> > managed to introduce other warning levels in the past.
> 
> That approach does not help *me* or drm, i915 and xe in the least. They
> are already fixed, and we want a way to keep them fixed. This is how all
> of this got started.

I imagine you'd include a way to have the 'make header_check' run on
some subset of files only, then use that in your CI for the interm.

> Your goal may be to make everything self-contained, but AFAICS there is
> no agreement on that goal. As long as there's no buy-in to this, it's
> not possible fix everything, it's an unreachable goal.

I didn't see that. I saw technical problems with the implementation
that was presented. I'd be shocked if there was broad opposition to
adding missing includes and forward declaration to most headers. It is
a pretty basic C thing. :\ 

Until someone sends a series trying to add missing includes and
forward declarations we can't really know..

> Arguably the situation is similar to W=1 builds. We can't run W=1 in our
> CI, because of failures outside of the drivers we maintain. 

You can run W=1 using a subdirectory build just for your drivers.

> Even if I put in the effort to generalize this the way you prefer, I
> guess a few kernel releases from now, it still would not do what we have
> already in place in i915 and xe. And, no offense, but I think your
> proposal is technically vague to start with. I really don't know where
> the goal posts are.

Well, I spent a little bit and wrote a mock up and did some looking at
how much work is here. Focusing on allnoconfig as a starting point,
293 out of 1858 headers failed to build, and with some fiddling I got
it down to 150, a couple of hours would get patches made for the vast
majority of it.

https://github.com/jgunthorpe/linux/commits/hdrcheck/

I don't see the same dire view as you do, it seems reasonable and doable.

Jason

  reply	other threads:[~2025-04-08 16:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-02 12:46 [PATCH v2 0/4] kbuild: resurrect generic header check facility Jani Nikula
2025-04-02 12:46 ` [PATCH v2 1/4] kbuild: add " Jani Nikula
2025-04-02 12:46 ` [PATCH v2 2/4] drm: switch to " Jani Nikula
2025-04-02 12:46 ` [PATCH v2 3/4] drm/i915: " Jani Nikula
2025-04-02 12:46 ` [PATCH v2 4/4] drm/xe: " Jani Nikula
2025-04-02 13:09 ` ✗ Fi.CI.BUILD: failure for kbuild: resurrect " Patchwork
2025-04-02 16:06 ` [PATCH v2 0/4] " Linus Torvalds
2025-04-03  7:06 ` ✗ CI.Patch_applied: failure for " Patchwork
2025-04-04  6:17 ` [PATCH v2 0/4] " Masahiro Yamada
2025-04-07  7:17   ` Jani Nikula
2025-04-07 17:12     ` Jason Gunthorpe
2025-04-08  8:27       ` Jani Nikula
2025-04-08 16:01         ` Jason Gunthorpe [this message]
2025-04-08 18:42           ` Jani Nikula
2025-04-08 20:15             ` Jason Gunthorpe
2025-04-08 19:48         ` Linus Torvalds

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=20250408160127.GD1778492@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=simona.vetter@ffwll.ch \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.