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

James Bottomley
2021-09-10T22:35:09Z

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