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

[Christian Brauner <christian.brauner@ubuntu.com>]

On Fri, Sep 10, 2021 at 02:32:48PM -0700, Josh Triplett wrote:
> On Fri, Sep 10, 2021 at 03:00:58PM -0600, Jonathan Corbet wrote:
> > There has been a regular disagreement in recent years about whether
> > drivers for accelerators (such as for the Habana Gaudi device) should be
> > subject to the same requirements as GPU drivers when it comes to the
> > availability of a free implementation of the user-space side.  It flared
> > up again recently:
> > 
> >    https://lwn.net/Articles/867168/
> > 
> > Happily, the Habana situation in particular seems to be resolving
> > itself:
> > 
> >    https://lwn.net/ml/linux-kernel/CAFCwf119s7iXk+qpwoVPnRtOGcxeuZb3rnihf6NWWoVT-4ODHA@mail.gmail.com/
> > 
> > But even there it is clear that the fundamental question has not yet
> > been resolved.
> > 
> > This seems like the sort of question that the maintainer summit exists
> > to address.  Specifically, we could discuss:
> > 
> >  - Under which circumstances should the kernel community require the
> >    existence of freely licensed user-space code that exercises all
> >    functionalities of a proposed kernel driver or feature?
> 
> I think it'd be reasonable to ask, as well: if we required this for
> *all* kernel functionality, such that we never add any userspace
> interface to the kernel unless there's *some* Open Source userspace that
> needs/wants it, what problems would that cause if any?
> 
> It appears that in this case the kernel pushing back has influenced the
> release of Open Source userspace code. Having a kernel-wide policy here
> seems like it'll *help* people within many companies to push for such
> changes: "We're never going to be able to get our changes into the
> upstream kernel if there's no userspace to drive them."

I can certainly see why that discussion is needed for features that deal
with hardware which requires an elaborate userspace component in order
to work.
But I'm not convinced this policy makes sense for all kernel features.
For example, when we introduce a new general api in kernel core it will
often be driven by requirements of other well-known open source
projects. If such projects state that they will add support for it once
a kernel supporting this feature is released that expression of their
intent is often sufficient. We usually don't make such projects jump
through the hoops of implementing the userspace side upfront to proof
that they would use it. Although to the credit of a few open source
projects that does also happen. But I'm hesitant to make this a general
rule.

Christian