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

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

Hello,

On Sun, Sep 12, 2021 at 11:00:47AM +0300, Leon Romanovsky wrote:
> On Sun, Sep 12, 2021 at 09:46:48AM +0200, Mauro Carvalho Chehab wrote:
> > Em Sun, 12 Sep 2021 07:27:55 +0300 Leon Romanovsky escreveu:
> > 
> > > > What if we're dealing with a device that only exists in a handful of
> > > > machines though ? Would distributions accept the burden of packaging
> > > > corresponding userspace code, and maintaining the packages, when only a
> > > > handful of people in the world will use it ? It's a genuine question.  
> > > 
> > > Fedora, Debian and OpenSuSE are volunteer based distributions, they
> > > accept new packages, which need to be prepared (or asked to be
> > > prepared) by such vendors.
> > > 
> > > There is no "accept the burden of packaging corresponding userspace code,
> > > and maintaining the packages", it is on package maintainer who can or
> > > can't be associated with distribution.
> > 
> > There is a dead lock issue, though: if we're willing to have a policy
> > of only accepting a new Kernel API after Fedora/Debian/openSuse accepts
> > its userspace counterpart, it would mean, in practice, that no new
> > APIs will ever be added, as I'm pretty sure most Fedora/Debian/openSuse
> > maintainers will refuse an application that depends on a non-accepted
> > Kernel API.
> 
> I said something different - "I would like to see any userspace API used (or to be
> used)". 
> https://lore.kernel.org/ksummit/20210912003349.6d2cacb1@coco.lan/T/#m3b7fbbe0959f1b59288dec9afd39f7cda0eeefe9
> 
> "To be used" means some open PR to existing package or request for
> inclusion for new packages.

Requiring userspace support to be merged in the appropriate framework or
accepted as a package by distributions can result in deadlocks, but
requiring only aa upstream pre-approval is I think a good way to deal
with the issue. That's what DRM/KMS does, there's no hard requirement
(as far as I can tell) to have code merged in Mesa before the kernel,
only a requirement of getting the Mesa code reviewed and acked.

> > As a maintainer of several Fedora packages myself, I would refuse
> > any attempts of adding support for a non-accepted kernel API on
> > the packages I maintain.
> > 
> > -
> > 
> > Also, it makes no sense to add support on such general-purpose
> > distros for some hardware that will never be supported by it.
> > 
> > See, there are, for instance, some types of hardware that are
> > specific for some industry, like for instance, the CAN bus.
> > While CAN buses remain restricted to vehicles, it won't make any 
> > sense to crowd a general purpose distro with support for such
> > hardware. Such distros are not certified with ASIL. So, they
> > aren't allowed by law to be used inside vehicles.

I'm not sure that's the best example, CAN has uses in other types of
devices, some of which may run a general-purpose distribution.

> And github pile of ... is certified?
> 
> In attempt to find general solution for all types of APIs and devices,
> we won't solve anything.

That I agree with.

> So I suggest to return and talk about AI/ML devices and APIs that
> targeted for enterprise/cloud and needs to be supported by major
> distros.

And that I don't :-) I think the issue is the same for at least GPUs and
AI/ML accelerators, and quite possible camera ISPs too. I'd like to try
and define clear sets of criteria to address the problem, and that can
include different alternatives (just as an example, not necessarily
something I'd advocate for, open userspace vs. documentation) that
subsystems can then select based on their specific situation.

-- 
Regards,

Laurent Pinchart