[RFC] new uapi policy for drm

Rodrigo Vivi rodrigo.vivi at intel.com
Tue Oct 15 20:55:41 UTC 2019


On Tue, Oct 15, 2019 at 04:16:00AM +1000, Dave Airlie wrote:
> I've kicked this around in my head over the past few weeks but wanted
> to get some feedback on whether it's a good idea or what impact it
> might have that I haven't considered.
> 
> We are getting requests via both amdgpu/amdkfd and i915 for new user
> APIs for userspace drivers that throw code over the wall instead of
> being open source developed projects, but we are also seeing it for
> android drivers and kms properties, and we had that i915 crappy crtc
> background thing that was for Chrome but Chrome didn't want it.
> 
> Now this presents a couple of issues:
> 
> a) these projects don't seem to that good at following our development
> guidelines, avoid developing userspace features in parallel in the
> open and having good development implementations before submitting
> upstream.
> 
> b) these projects don't have experienced userspace developers
> reviewing their kernel uapis. One big advantage of adding uapis with
> mesa developers is they have a lot of experience in the area as well.
> 
> It's leading me to think I want to just stop all uapi submissions via
> driver trees, and instead mandate that all driver uapi changes are
> sent in separate git pull requests to dri-devel, I'd try (with some
> help) to catch all uapi modifications in normal trees, and refuse
> pulls that modified uapi.

I truly see your reass and a separated pull request would even
give more visibility to the UAPI changes for everyone. My only concern
would be the flow of merging this on different repositories, etc...

So I'd prefer if we could keep on the simplest side.

> 
> At least I'm considered writing the script and refusing and pulls that
> have a uapi change that doesn't contain a link to the userspace
> changes required for it in a public developed repo.

This is a great idea.

Probably better if we could enforce that on "dim" so we couldn't even
merge a uapi without a link.

Would you consider a different tag for that:

UAPI: https://gitlab.../code.c

"Reference:" should be enough, but that could very easily bypass any script
and a new tag would make the changes even more visible in a way that
the separate pull request wouldn't be needed.

> 
> Thoughts?
> 
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


More information about the dri-devel mailing list