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.