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

On Mon, 10 Aug 2026 09:32:24 -0400
James Bottomley <[email protected]> wrote:

> > MM may be a large and critical subsystem, but most hardware acts
> > pretty much the same.  
> 
> Have you met some of the weird architectures with their super strange
> VM extensions and the even weirder confidential computing extensions?

But they are "weird architectures". That is, basically something that is
not the norm, and needs to work with the main core to come up with
solutions. Heck this is what we had to do to get RT working. 

> 
> >  Where most developers are working together on a common
> > platform. Even with minor differences between architectures.
> > Architecture specifics of how to create memory mappings can be mostly
> > be abstracted out.  
> 
> 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 know DRM at all, but just from listening to Dave, it sounded
> > to me like everyone is doing things their own way and Dave needs to
> > manage it all with a more complex process. Where networking and arm
> > may be the only ones to rival the complex process of DRM.  
> 
> 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.

Perhaps we can look at the process of these other big subsystems to see how
it could help out DRM. Maybe this would make Dave's job easier?

-- Steve