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

Laurent Pinchart
2021-09-12T16:58:39Z

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.

--
Regards,

Laurent Pinchart