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

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

On Fri, 2021-09-10 at 23:59 +0200, Alexandre Belloni wrote:
> On 10/09/2021 14:51:43-0700, James Bottomley wrote:
> > On Fri, 2021-09-10 at 15:00 -0600, Jonathan Corbet wrote:
> > >  - Are there internal kernel interfaces, such as DMA-BUF or
> > > P2PDMA, that are only available to drivers with a free user-space
> > > implementation? Do we need an EXPORT_SYMBOL_USERSPACE_GPL()?
> > 
> > I don't think reasonably we can do this.  The kernel GPLv2 licence
> > includes this system exception:
> > 
> >       NOTE! This copyright does *not* cover user programs that use
> >    kernel services by normal system calls - this is merely
> > considered
> >    normal use of the kernel, and does *not* fall under the heading
> > of
> >    "derived work". Also note that the GPL below is copyrighted by
> > the
> >    Free Software Foundation, but the instance of code that it
> > refers to
> >    (the Linux kernel) is copyrighted by me and others who actually
> >    wrote it.
> > 
> >     Also note that the only valid version of the GPL as far as the
> >    kernel is concerned is _this_ particular version of the license
> > (ie
> >    v2, not v2.2 or v3.x or whatever), unless explicitly otherwise
> >    stated.
> > 
> > This means currently that once an API is exposed to user space,
> > we've given up control of the type of programme (proprietary or
> > open source) that may use it.
> > 
> > It might be possible legally to try and take back that control by
> > modifying the system exception (what is a "normal" system call),
> > but I personally think that would be unwise and create a raft of
> > other problems for other proprietary user space code running on
> > Linux, which I really think we don't want to do.
> > 
> > I think our only recourse for user space accelerators is not to
> > export the interface if we think it would only be used for evil
> > purposes.
> > 
> 
> 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.

James