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