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

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

Hi Daniel,

On Mon, Sep 13, 2021 at 03:57:25PM +0200, Daniel Vetter wrote:
> On Mon, Sep 13, 2021 at 3:50 PM Christian Brauner 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.

I concur here. I've spent the past 3 years working on libcamera in
userspace after a decade of experience in the kernel side of V4L2. It
was an enlightening (and embarassing) moment to realize that some kernel
APIs that I had designed myself didn't stand the test of being used for
real. A test application written to test an API in the way the API was
designed will generally not be good at finding design flaws.

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

-- 
Regards,

Laurent Pinchart