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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi James,

On Sat, Sep 11, 2021 at 08:24:38AM -0700, James Bottomley wrote:
> On Sat, 2021-09-11 at 08:51 -0600, Jonathan Corbet wrote:
> > James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> > 
> > > On Fri, 2021-09-10 at 23:59 +0200, Alexandre Belloni wrote:
> > > > I think the question is not whether we want to forbid proprietary
> > > > user space using an API but whether we want to merge said API so
> > > > the license on the kernel doesn't matter much.
> > > 
> > > I thought that *was* the statement I made in the last paragraph: we
> > > can choose whether or not to merge the enabling API into the
> > > kernel. However, if we merge it we can't choose whether a
> > > proprietary user space takes advantage of the API.  My original
> > > reply was to the notion of EXPORT_USERSPACE_GPL, which I think we
> > > have no legal basis for enforcing without modifying the system
> > > exception.
> > 
> > That wasn't thinking when I pulled the idea of EXPORT_USERSPACE_GPL
> > out of whatever dark place it was lurking in.
> 
> OK, but you can see how that thought is arrived at since
> EXPORT_SYMBOL_GPL is a technically enforced licensing permission tag. 
> However, I was seriously pushing back against the *idea* of such a tag
> because once it crosses the kernel to user boundary it would cause huge
> confusion of our current licensing positions ... regardless of what it
> actually means.
> 
> >   The idea was, instead, to document that if your driver is using
> > that interface, it won't be considered for merging into the kernel in
> > the absence of a working, free, user-space implementation -- should
> > we choose to adopt such a policy, of course.
> 
> Right, and if you have a driver with an internal API that's used for
> communication with a userspace blob, we can evaluate that, as we have
> done before, on a case by case basis.  It's not a new thing, because
> we're both old enough to remember "my wireless driver has to have a
> proprietary component for regulatory reasons".
> 
> We've made decisions both for and against such drivers in the past, but
> I think the issues are too nuanced to make a general rule.  If you do
> have a general rule, what other things, like firmware, would get caught
> by it and so on ...
> 
> > Nobody is trying to prohibit proprietary user space, that's not the
> > point.
> 
> I didn't think you were in general, but requiring a free userspace
> driver implementation is prohibiting a proprietary one and so then you
> get into questions of how wide the reach is and what the knock on
> effects are if you try to craft a general policy around this ...
> especially if it has technical enforcement measures.

Requiring the existence of one open userspace implementation doesn't
preclude the ability for vendors to develop and ship closed
implementations in parallel, at least in the general case. For instance,
with GPUs or cameras, an open implementation could be developed (in Mesa
and libcamera respectively) to exercise the device features (such as the
GPU shader instruction set, or the camera ISP processing parameters),
but wouldn't be required to include all the tuning and optimizations
that a closed implementation would typically have. A vendor could thus
ship a closed-source shader compiler in its OpenGL/Vulkan userspace
driver, protecting the R&D investment to implement those optimizations
(this would most likely also include lots of hacks to please
benchmarks), and the community would be able to use the GPU and improve
the open implementation.

For GPUs, the situation has been quite clear for years: if a vendor
wants an upstream driver, with all the benefits this brings, they have
to also provide a (mostly?) feature-complete (in the sense of hardware
features) but not necessarily optimized open-source counterpart. We're
exploring here whether or not the same deal should cover camera ISPs and
ML/AI accelerators (and possibly other devices that I'm less familiar
with).

For a wireless driver the situation is possibly different, I suppose
that if the closed-source userspace blob is there only for regulatory
reasons, then there would be very little point in having a closed-source
implementation with a parallel one.

-- 
Regards,

Laurent Pinchart