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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Dave,

On Mon, Sep 13, 2021 at 05:13:05AM +1000, Dave Airlie wrote:
> 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

Thank you for that effort. Could you add camera ISPs to the list with
FPGAs, DSPs and ML accelerators ?

You mention Level0 in that document. I assume you don't mean the
OpenStreetMap editor ?

-- 
Regards,

Laurent Pinchart