On Wed, Apr 02, 2025 at 04:53:37PM +0300, Jani Nikula wrote: > On Wed, 02 Apr 2025, Jason Gunthorpe <j...@nvidia.com> wrote: > > On Wed, Apr 02, 2025 at 03:56:37PM +0300, Jani Nikula wrote: > >> On Tue, 01 Apr 2025, Jason Gunthorpe <j...@nvidia.com> wrote: > >> > On Tue, Apr 01, 2025 at 10:42:35PM +0300, Jani Nikula wrote: > >> >> On Tue, 01 Apr 2025, Jason Gunthorpe <j...@nvidia.com> wrote: > >> >> > So, I'd suggest a better way to run this is first build the kernel, > >> >> > then mine the gcc -MD output (ie stored in the .XX.cmd files) to > >> >> > generate a list of headers that are actually part of the build, then > >> >> > only test those. That eliminates all the kconfig problems. Opt out any > >> >> > special headers that really have a good reason not to be stand alone. > >> >> > >> >> I think we'd want the drm headers pass the checks independent of configs > >> >> (apart from CONFIG_DRM). One size doesn't fit all. > >> > > >> > Why? That demand is just making it impossible to make shared > >> > infrastructure, and I don't think DRM should go off and build its own > >> > stuff just for DRM in a way that nobody else can use it. > >> > > >> > If you really, really, care then you can have your makefile codegen an > >> > "allheaders.c" that #includes drm/*.h and compile that. > >> > >> The v2 series [1] generalizes the header checks and it's no longer in > >> any way dependent on DRM. For starters, each subsystem/driver needs to > >> decide for themselves which headers are to be checked. > > > > Yuk. The idea at the top of this email is alot better. Why don't you > > implement it? > > Because quite frankly I don't have the time, and I've already spent a > disproportionate amount of the time I didn't have on hiding the turds on > the existing header test thing this week. > > >> This can be expanded with more clever ways to choose the headers to > >> check. But we have to start *somewhere*. > > > > Bah, that argument only works if nobody has better ideas. There are > > meaningful technical problems with your approach, and proposed > > solutions here. > > There are also meaningful social problems with the approach of making > people do a lot of stuff they didn't have time to do in the first place, > just to end up not merging any of it ever. > > What I've been focusing on is to fix this stuff enough to make it work > for 6.15. If it's accepted, *maybe* I'll look at further improvements > for the next merge window. And if there's enough interest, there's a > baseline for others to build on. But right now, seems to me it could all > just be reverted in a whim, with all the time wasted.
Yeah, this header test stuff is clearly not as easy as it looks. Even for drm Jani had to fix up a few things every time this effort was restarted, and we have very modular and clean headers and really try to make them stand-alone. Rolling this out as a flag day change is just not realistic I think, it's just setting yourself up for failure. I think there's two real optiosn here: - Gradually roll this out, ideally with support in main Kbuild so it doesn't have to be replicated. - Just shoot it down and move on. This isn't a refactoring, it's pretty substanstial change in how headers work and how people need to treat them. And you just never change people with a flag day approach, that doesn't ever work. And if you try, you'll just piss of a lot of folks who are taken by surprise by your change. Cheers, Sima -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
