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

[Mauro Carvalho Chehab <mchehab@kernel.org>]

Em Fri, 10 Sep 2021 15:00:58 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:

> 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?
> 
>  - 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()?
> 
>  - What constitutes an acceptable user-space implementation in cases
>    where these restrictions apply?
> 
> I suspect that more clarity (and fewer arguments) on these questions
> would be welcome both within and beyond the development community.

The media subsystem also has this sort of issues: there are several
drivers there to support hardware accelerators for video encoders and 
decoders. In the case of media, usually devices with such hardware have
an Image Signal Processor, where the codec runs on some firmware.

On media, enforcing userspace to always be open source would
have been very bad, as it would prevent several videoconferencing 
software to exist on Linux.

Also, there are several such codec hardware that only exists on 
embedded hardware that already depends on proprietary software 
to run.

So, a policy like that would make more damage than good.

What we do, instead, is to try to enforce that the userspace API to
be fully documented in a way that open source software can exist.

This is easier said than done, but we have some compliance tools
that we use, in order to help to validate the uAPI implementations.

Thanks,
Mauro