Re: [RFC] new uapi policy for drm

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Tue, Oct 15, 2019 at 01:55:41PM -0700, Rodrigo Vivi wrote:
> 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

I truly see your reasons....

(and I can't even blame an auto-corrector... sorry)

> 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@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel