Re: [MAINTAINER SUMMIT] User-space requirements for accelerator drivers

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sun, 2021-09-12 at 19:58 +0300, Laurent Pinchart wrote:
> On Sun, Sep 12, 2021 at 09:43:39AM -0700, James Bottomley wrote:
> > On Sun, 2021-09-12 at 18:55 +0300, Laurent Pinchart wrote:
> > > As mentioned in another part of the mail thread, requiring code
> > > being merged in upstream userspace projects and/or packaged by
> > > distributions will cause deadlocks, but requiring code to be
> > > submitted and (pre-)approved is workable. That's what DRM/KMS
> > > does. To upstream a new KMS property for instance, you need to
> > > show how it's going to be used in Weston/Xorg/Android/... by
> > > submitting patches, and have the overall architecture approved by
> > > the corresponding maintainers.
> > 
> > This is no different from interlocks required in pretty much every
> > other project crossing open source feature, so it seems like the
> > right approach to me.  We already use this for confidential
> > computing, which often requires interlocking changes to QEMU, edk2
> > and other tools.  Usually, for confidential computing, the
> > evaluation is on either the QEMU or edk2 list which then accepts
> > the patch and the rest of the projects follow.  We do,
> > occasionally, get a late objection to the API from one of the other
> > projects after part of the enabling code has gone upstream in the
> > others, but we handle this like a bug fix.
> 
> On the DRM/KMS side that's also handled fine as far as I know, as
> mentioned above. For cameras, libcamera is becoming the de facto
> standard userspace stack, so we'll have a solution too. The harder
> question is what to do when no standard userspace stack exists. The
> answer obviously is to create one (or possibly multiple
> alternatives), but we'll need more than wishful thinking to make that
> happened. I can tell it took lots of work for libcamera to see the
> light of the day, including on the business side of it, not just the
> technical side.

Well, you know, this is where Open Source as a Standard comes from.  We
see the same in Confidential Computing.  There are several
manufacturers and they always specify how they think their stuff should
work in their standards or code drops, but rarely get beyond a proof of
concept in their own labs.  Once we start moving it upstream, we find
points of similarity between the different chip vendors, or sometimes
specified implementations which plain don't work, and start modifying
the APIs to take this into account.  What we eventually end up with
often doesn't mirror what the manufacturer standard says but it ends up
being the actual standard for current and future confidential computing
chips.

James