[RFC] new uapi policy for drm

Wed Oct 16 19:28:14 UTC 2019

On Wed, Oct 16, 2019 at 10:28 AM Matt Roper <matthew.d.roper at intel.com> 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.
>
> Having submitted "that i915 crappy crtc background thing" it's unclear
> to me what you're trying to say here.  If you're trying to claim that
> this was "thrown over the wall" or that there was an attempt to try to
> sneak this work in under the radar and circumvent uapi policy then you're
> way off track and you probably need to review the (long) history of this
> feature.  We've very religiously followed both the spirit and the letter
> of your upstream uapi policy with regards to that feature and taken great
> care to ensure it would *not* land upstream without an actual opensource
> userspace consumer.  There was some confusion recently about how
> ChromeOS was/wasn't using this interface, but the Google guys helped
> clear that up, and the kernel changes have now returned to their holding
> pattern and will not go upstream unless new userspace emerges.  To
> refresh your memory on the history:
>
>  * The proposed interface was originally posted in 2015/2016 as an FYI
>    to find out if any opensource userspace projects might have a use for
>    this functionality (we already had the patches written since there's
>    non-opensource software that requires it).  The cover letters at the
>    time clearly stated that it should not be merged upstream since there
>    was no userspace:
>
>         "Note that this series isn't mergeable yet since we don't (yet)
>         have an open source userspace that can make use of it"
>         (https://lists.freedesktop.org/archives/intel-gfx/2016-February/087382.html)
>
>  * About 2.5 years later there was suddenly interest expressed both from
>    people involved in Weston and people involved in ChromeOS, and they
>    independently asked for refreshed kernel patches.  When the refreshed
>    patches were posted  they again included a disclaimer that we needed
>    proper userspace before it could land:
>
>         "As always, we'll still need the patches for at least one of
>         those projects to get posted (and reviewed) somewhere public
>         before we actually merge these kernel patches."
>         (https://lists.freedesktop.org/archives/intel-gfx/2018-October/178202.html)
>
>  * The Weston effort apparently fizzled out, but at the beginning of
>    2019 we were directed to some patches to the ChromeOS ozone layer
>    (https://chromium-review.googlesource.com/c/chromium/src/+/1278858)
>    that utilized the interface.  I'm not at all familiar with the
>    ChromeOS userspace stack, but since the Ozone code was reviewed by
>    non-Intel folks and shows as 'merged' that sounded like a legitimate
>    open source userspace consumer.  From that point on the Chromium
>    review links were clearly advertised in the cover letter each time
>    the series was respun so that it would be very clear what the
>    expected userspace was and so any concerns could be raised.
>
>  * Daniele and Sean from Google recently brought it to our attention
>    that even though that ozone code made use of the background color
>    property, the ozone interfaces themselves don't get used at higher
>    levels of the ChromeOS stack (and had probably been merged to the
>    ozone layer in error).

Yes I think we (at Google) more or less all assumed that someone else
was going to consume the ozone API (at least that's what I did). And
because everyone assumed someone else might make use of it, that code
ended up landing. I am sorry about that; we'll try to be more careful
in the future. As you say the ozone code doesn't provide any feature
in itself, it's just plumbing. Obviously a feature on top didn't
materialize.

The exact process to fix this isn't really relevant to me, but I think
maybe we should have more open discussions when new features like this
happen. Ask ourselves "Who will make use of this feature?" and check
with that person seems like a good start. At least then, we have a
contact point to ask further questions. Maybe through that process we
would find that this is just ozone code, and there is no consumer on
top. Or we can dig into exactly what's needed to allow shaping the
APIs.

Best,
Stéphane

>
> Once they helped us understand that the
>    properties wouldn't ultimately be utilized in a meaningful way with a
>    real ChromeOS setup today, we put a halt to the upstreaming effort:
>
>         "Hmm, in that case it sounds like we probably don't actually
>         have enough userspace support yet to justify merging the kernel
>         changes at this time."
>         (https://lists.freedesktop.org/archives/dri-devel/2019-October/239436.html)
>
> So long story short, we've been very transparent about what's going on
> with this feature for the whole ~4 years it's been floating around.  I
> would hope that you, as DRM maintainer, would have spoken up at some
> point if you felt there was something else that needed to be handled
> differently.  No code for this api has ever landed in any of the driver
> trees, so I'm not sure why you called out this work in an email
> proposing a change to uapi pull requests.
>
> > 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.
>
> FWIW, requiring a link to the corresponding userspace in the kernel
> patch itself and not just the series cover letter seems like a
> reasonable request to me.
>
>
> Matt
>
> >
> > Thoughts?
> >
> > Dave.
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel