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

[Mauro Carvalho Chehab <mchehab@kernel.org>]

Em Sun, 12 Sep 2021 17:53:51 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

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

Surely. That's why I added the "While CAN buses remain restricted to 
vehicles" on the above phrase. This was created for a demand from
one specific industry, by it could be used on other places.

The same happened in the past with cameras that required an ISP
IP block: they started being used only on embedded, but migrated 
to laptops and other devices after some time.

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

A maintainer's summit discussion is the forum for discussing issues
that cross multiple subsystems. AI/ML is not the first case where
new APIs are needed, nor will be the last one. 

So, while I agree that AI/ML should be discussed, it can't stop on
it, as similar issues happen on other subsystems.

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

Agreed.

Thanks,
Mauro