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

[Daniel Vetter <daniel.vetter@ffwll.ch>]

On Mon, Sep 13, 2021 at 3:50 PM Christian Brauner
<christian.brauner@ubuntu.com> wrote:
> 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.

I agree it's an orthogonal discussion, but I think we've also had our
fair share of fully generic interface that turned out to miss the mark
in real-world usage. This is why the generic kernel
modesetting/display interface for drivers in drivers/gpu also needs
fully open implementation. Not because we really need that for
long-term maintainability - the interfaces are generally well-defined
enough that testcases + docs are sufficient for that, but because in
practices it just catches so many small gotchas that are otherwise
overlooked in good generic uapi design.

But I do think we should keep this apart from the discussions for hw
drivers, where 80+% of the driver that's absolutely needed to drive
the hardware is in userspace.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch