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

[Josh Triplett <josh@joshtriplett.org>]

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."

One tradeoff would be, in theory, that there are some vendors who won't
care enough about upstreaming their changes, and will just keep their
drivers out of tree in that circumstance. There was a time where that
would have been reason enough not to have such a policy. I think that
time has passed, though, and now I think we'd get more benefit from
requiring open userspace consumers of APIs than we'd lose by having some
APIs not submitted upstream. (Plus, those vendors are still obligated to
*ship* the source of those changes to their users, and if a third party
wants to use those changes they can always upstream them, at which point
the vendor still faces the choice of "do I want/need to participate in
this conversation or not".)

>  - What constitutes an acceptable user-space implementation in cases
>    where these restrictions apply?

This seems like it'll always be a fuzzy line. The main issue: it's OK if
there are both open and proprietary users, but it's not OK if the only
open implementation is an outdated or token project that nobody actually
uses, that exists and is maintained solely for the purposes of placating
the kernel requirement. There's no easy way to define that line, other
than "we'll know it when we see it".