[PATCH v2 0/4] kbuild: resurrect generic header check facility

[Jani Nikula]

On Mon, 07 Apr 2025, Jason Gunthorpe <jgg at 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.

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.

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. Thus we add
most W=1 checks manually in our Makefiles, and keep our drivers warning
free. This is what we want for headers too. But the key difference is
that there *is* general consensus that W=1 fixes should be merged.

Perhaps inadvertently, you're making it harder for the people who are on
board with your goal to do their part of the job in their corner of the
kernel.

> If you added the infrastructure there is a whole list of people on
> kernel-janitors that would probably help with the trivial cleanups to
> make it run clean.
>
>> With this type of antagonistic rather than encouraging attitude towards
>> contributions, there's just no way I can justify to myself (or my
>> employer) spending more time on what looks like a wild goose chase. I
>> have zero confidence that no matter what I do I'd get approval from you.
>
> I think you've been given a clear direction on what would be accepted
> and have the option to persue it. Claiming that is "antagonistic"
> seems unnecessary.

I have to disagree on both of those points.

>> And this is the primary reason subsystems and drivers hack up stuff in
>> their little corners of the kernel instead of sticking their necks out
>> and trying to generalize anything.
>
> Seems to me like this is the usual case of generalizing being actually
> hard, you almost always have to actually do more work to succeed.

I think you and me both share the idea that most headers should be
self-contained. Neither Linus nor Masahiro seem to think that is
generally true. I've provided a way to opt-in for the checks. Linus
seems to find the approach acceptable. You and Masahiro don't.

I think I'm at an impasse.

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.


BR,
Jani.


-- 
Jani Nikula, Intel