Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

Mark Brown <[email protected]> Mon, 10 Aug 2026 16:23:41 +0100
Newsgroups	dev.linux.lists.ksummit
Message-ID	<[email protected]>
On Mon, Aug 10, 2026 at 10:24:23AM -0400, Steven Rostedt wrote:
> James Bottomley <[email protected]> wrote:

> > True (well mostly), but the internal complexity is concealed within an
> > external abstraction rather than having it spill all over the kernel
> > ... I would hope DRM does the same.

> That's a good question for Dave Airlie. Is it possible to make a general
> abstraction with DRM (much like VFS)? It sounded to me that the "weird
> architectures" of DRM was the norm not the exception. Perhaps it is more
> like what ARM was before Linus told them to get their act together.

I don't think any of that stuff is really what's causing issues with DRM
externally - for -next the issues I see are the constant cherry picking
(which I gather is also an issue for stable), and outside of that the
thing that comes up a lot is that it can be hard to get someone to take
responsibility for actually applying a patch if you're not a DRM person
since the responsibility is more diffuse.  This can lead to issues like:

  https://lore.kernel.org/r/[email protected]

or things where the DRM parts of a cross tree series look like they're
being ignored.

> > If your assumption is correct, this is internal cat herding ... MM has
> > much the same problem except that it has to deal with somewhat
> > opinionated architecture maintainers (around 22 of them) to agree on
> > the internal abstractions for MM primitives.  Perhaps rather than
> > getting into my problem is bigger than yours type arguments, we could
> > observe that MM might run a bit more smoothly because it gets an
> > additional 3 day conference (LSF/MM) plus a MC at Plumbers to sort
> > itself out?

> I guess the question is, what exactly is being big for DRM that it needs to do
> cherry-picking for their linux-next branch whereas Networking and ARM do
> not? Is DRM bigger than either of those? From what I understand VFS doesn't
> have to do that either. And VFS has a large range of file systems to deal
> with. But it also has one of the best abstraction layers of the kernel.

It's not even all of DRM, it's specifically the AMD and Intel driver
stacks which as far as I can tell just routinely cherry pick all their
fixes between their development and fixes branches without even
considering the possibility of either merging up the fixes branch or
just waiting and letting the fixes propagate back.  None of the rest of
the DRM trees ever seems to cause these issues.
signature.asc (application/pgp-signature, 488 B)