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

[Dave Airlie <airlied@gmail.com>]

On Sat, 11 Sept 2021 at 07:10, Jonathan Corbet <corbet@lwn.net> 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?
>
>  - 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.
>
> Thanks,

Can everyone take a read of:

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

I think in order to clean the signal/noise ratio up in here, some
education effort might help people realise how non-trivial these
things are.

1. These drivers are not one or two ioctls that a few selftests and a
small test app can cover. It's like saying LTP is all we need to
define the uAPI for the kernel and if anyone does something LTP
doesn't cover the app is broken. These systems are generally complex,
multithreaded and multiuser uAPIs, involving command streams recorded
in userspace being submitted to the devices. They interact with memory
management and can cause unfindable deadlocks across the system if
designed incorrectly. Documentation or kselftests aren't going to cut
it here.

2. In my experience we don't build communities by merging everything,
we build them by saying No more and pushing back on companies with
education and cross-vendor cooperation. Responsible kernel maintenance
shouldn't end at the kernel boundaries. If you aren't the person to
help enforce a userspace for a driver you are being asked to merge,
then don't merge it, but try and engage the vendor with the
communities of interest in the kernel who already deal in those areas.

3. The pressures on these companies to merge things into Linux isn't
altruistic or even that they necessarily want to be in the Linux
kernel upstream. They are being told by Red Hat, Facebook, Google or
someone else that they need an upstream driver. They will generally
engage at a minimal level to get past that blockage and then
disengage. Having a clear set of rules (or a place to discuss those
rules, for new subsystems) and a gentle pushback helps develop
communities by unlocking funding within those larger areas. As Laurent
has said this isn't free, but just putting things into the kernel and
not caring about userspace hasn't built any Linux communities in the
accelerator areas.

That said I started writing a cleaned up version of the above document
which is more generic that other subsystems could sign on to. I was
going to engage with a coalition of like-minded maintainers rather
than trying to gain consensus among a herd of cats to see if we can
draw clearer lines in the sand that cross more subsystems so the
experience of drivers/gpu doesn't go unwasted but also isn't just
bypassed by subsystem hunting.

https://cgit.freedesktop.org/~airlied/linux/log/?h=wip-open-source-userspace

Dave.