Re: [RFC] new uapi policy for drm

From: Sean Paul <sean@poorly.run>
To: Dave Airlie <airlied@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC] new uapi policy for drm
Date: Wed, 16 Oct 2019 16:19:32 -0400	[thread overview]
Message-ID: <20191016201932.GZ85762@art_vandelay> (raw)
In-Reply-To: <CAPM=9txm6udXT9KtW=ROVMf2xRjd4sbPN9OPEQ--taP2vi-mmQ@mail.gmail.com>

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.

The Chrome issue this past week was really a communication breakdown between
everyone involved. The Chrome patch at first glance looks like it implements the
feature, so this type of thing really just needs to be caught by the left hand
talking to the right (which is what happened when Daniele and I talked at XDC).
At least in our (Chrome's) case, we'll catch this type of thing much earlier
next time and avoid the situation entirely. I think even under your new proposal
we would have been in the same spot (since this patchset is still in review).

> 
> 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.

We did this a separate pull with the initial HDCP support and it went Ok. I
think there was a bit of conflict pain between hdcp topic branch and drm-intel,
but we mostly got along.

That said, I do want to be sensitive to HW vendors trying to upstream their HW
features. We shit on them for keeping everything downstream, but then we shit on
them for missing the bar when they try to upstream. With Android moving to kms,
we're going to have more vendors coming forward with boutique HW features they
are looking to standardize (or maybe they'll just stay downstream -- I'll try to
stay optimistic). Nothing in your proposal suggests that it will be more
difficult for vendors to upstream the right way, just that we'll have more
oversight and a more consistent voice for UAPI. So yeah, I think that's
completely reasonable.

Sean

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

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel