[RFC] new uapi policy for drm

[Dave Airlie]

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.

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.

Thoughts?

Dave.