Re: [MAINTAINER SUMMIT] User-space requirements for accelerator drivers

[Dave Airlie <airlied@gmail.com>]

>
> So should we be forcing everyone to follow the IBM standard for
> accelerator drivers because they were in the kernel first all those
> years ago?  Or what other standard do we pick?
>
> And why are we dictating new industry standards here?  Who are we to do
> that?  Who is going to take that responsibility on?

There is no sane kernel API standards here, the standards that control
these devices live out in userspace, far away from the world you want
to inhabit. Responsible kernel maintainership should come with
knowledge of the entire ecosystem and where it's going. If people are
trying to merge kernel drivers and you don't have enough
info/knowledge about the ecosystem, then say No.

> >
> > Because dma-buf API has specific semantics and was designed with very
> > specific usage model in mind.
>
> So will the IB patches usage be re-reviewed?
>
> Anyway, we have apis that are used throughout the kernel all the time
> that don't end up on the various subsystem mailing list because people
> forget, or just do not know.  That's normal and something we have dealt
> with for forever.  As an example, I didn't realise that just using the
> dma-buf api required such a review.
>
> Can we put that in the MAINTAINERS file somehow for apis?

We have had MAINTAINERS rules matching on the dma-buf includes

78baee8d3b976a6a6a2c208e3a36d3f1e6297e6c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Dec 4 22:51:05 2019 +0100

    MAINTAINERS: Match on dma_buf|fence|resv anywhere
and a later followup to clean it up a bit.

> That is a great question and I do not have the answer to that.  Should
> we have done that after the first one went into the kernel all those
> years ago?  Maybe, but I seem to recal the answer being "our hardware
> works much differently, so our user api will be much different", and
> that's a valid answer.

Every GPU driver has a different user API, all of them there is no
standard. We still merge them but we require userspace. Maybe if you
could sign up to follow the same rules it might be less onerous on
you.

>
> It's a hard line to draw, and for some reason, I seem to be the one
> having to review these types of drivers every kernel release.  If people
> wish to help me out, please do so, all the patches are on the lists.

We do help out, we've said No. I've no idea why you go ahead and merge
things sometimes.

Creating a trash pile in your neighbourhood and then complaining when
more people continue to dump more trash on it seems a little
disingenuous to me.

We need to take more responsibility for the way these things are used,
and making sure there are frameworks for them.

We got things where they were by saying upstream first a lot without
thinking of the consequences of success. Now we have that success we
should start thinking of the responsibilities that come with it.
Distros like RHEL/Centos are why these vendors are pushing stuff
upstream, the want to be included. However once they do that they no
longer gain the benefits of the Linux development model and just run
off and spawn 20 userspace projects that they can maintain control
over. Companies love control, they hate not having ultimate say over
their kernel drivers, and they won't willingly create userspace
projects where that happens either, not unless we work together for
the good of the ecosystem, not just the good of the kernel.

Dave.