Message-ID: <Z-1MqJen5o0yhoQQ@phenom.ffwll.local>
Date: Wed, 2 Apr 2025 16:41:44 +0200
From: Simona Vetter <simona.vetter@...ll.ch>
To: Jani Nikula <jani.nikula@...ux.intel.com>
Cc: Jason Gunthorpe <jgg@...dia.com>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Airlie <airlied@...il.com>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm for 6.15-rc1

On Wed, Apr 02, 2025 at 04:53:37PM +0300, Jani Nikula wrote:
> On Wed, 02 Apr 2025, Jason Gunthorpe <jgg@...dia.com> wrote:
> > On Wed, Apr 02, 2025 at 03:56:37PM +0300, Jani Nikula wrote:
> >> On Tue, 01 Apr 2025, Jason Gunthorpe <jgg@...dia.com> wrote:
> >> > On Tue, Apr 01, 2025 at 10:42:35PM +0300, Jani Nikula wrote:
> >> >> On Tue, 01 Apr 2025, Jason Gunthorpe <jgg@...dia.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

Powered by blists - more mailing lists