From: Leon Romanovsky <leon@kernel.org>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Thomas Gleixner <tglx@linutronix.de>,
Josh Triplett <josh@joshtriplett.org>,
Jonathan Corbet <corbet@lwn.net>,
ksummit@lists.linux.dev
Subject: Re: [MAINTAINER SUMMIT] User-space requirements for accelerator drivers
Date: Sun, 12 Sep 2021 11:00:47 +0300 [thread overview]
Message-ID: <YT2zryAKHc/5R2IH@unreal> (raw)
In-Reply-To: <20210912094648.3296acfe@coco.lan>
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 <leon@kernel.org> 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.
>
> 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.
And github pile of ... is certified?
In attempt to find general solution for all types of APIs and devices,
we won't solve anything.
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.
Thanks
>
> Thanks,
> Mauro
next prev parent reply other threads:[~2021-09-12 8:00 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-10 21:00 [MAINTAINER SUMMIT] User-space requirements for accelerator drivers Jonathan Corbet
2021-09-10 21:32 ` Josh Triplett
2021-09-13 13:50 ` Christian Brauner
2021-09-13 13:57 ` Daniel Vetter
2021-09-14 2:07 ` Laurent Pinchart
2021-09-14 14:40 ` Jani Nikula
2021-09-14 14:45 ` Geert Uytterhoeven
2021-09-14 14:59 ` Jani Nikula
2021-09-14 15:10 ` Geert Uytterhoeven
2021-09-10 21:51 ` James Bottomley
2021-09-10 21:59 ` Alexandre Belloni
2021-09-10 22:35 ` James Bottomley
2021-09-11 14:51 ` Jonathan Corbet
2021-09-11 15:24 ` James Bottomley
2021-09-11 21:52 ` Laurent Pinchart
2021-09-14 13:22 ` Johannes Berg
2021-09-11 0:08 ` Laurent Pinchart
2021-09-10 22:52 ` Mauro Carvalho Chehab
2021-09-10 23:45 ` Josh Triplett
2021-09-10 23:48 ` Dave Hansen
2021-09-11 0:13 ` Laurent Pinchart
2021-09-10 23:55 ` Thomas Gleixner
2021-09-11 0:20 ` Laurent Pinchart
2021-09-11 14:20 ` Steven Rostedt
2021-09-11 22:08 ` Laurent Pinchart
2021-09-11 22:42 ` Steven Rostedt
2021-09-11 23:10 ` Laurent Pinchart
2021-09-13 11:10 ` Mark Brown
2021-09-11 22:51 ` Mauro Carvalho Chehab
2021-09-11 23:22 ` Mauro Carvalho Chehab
2021-09-11 10:31 ` Leon Romanovsky
2021-09-11 11:41 ` Laurent Pinchart
2021-09-11 12:04 ` Leon Romanovsky
2021-09-11 22:04 ` Laurent Pinchart
2021-09-12 4:27 ` Leon Romanovsky
2021-09-12 7:26 ` Greg KH
2021-09-12 8:29 ` Leon Romanovsky
2021-09-12 13:25 ` Greg KH
2021-09-12 14:15 ` Leon Romanovsky
2021-09-12 14:34 ` Greg KH
2021-09-12 16:41 ` Laurent Pinchart
2021-09-12 20:35 ` Dave Airlie
2021-09-12 20:41 ` Dave Airlie
2021-09-12 20:49 ` Daniel Vetter
2021-09-12 21:12 ` Dave Airlie
2021-09-12 22:51 ` Linus Walleij
2021-09-12 23:15 ` Dave Airlie
2021-09-13 13:20 ` Arnd Bergmann
2021-09-13 13:54 ` Daniel Vetter
2021-09-13 22:04 ` Arnd Bergmann
2021-09-13 23:33 ` Dave Airlie
2021-09-14 9:08 ` Arnd Bergmann
2021-09-14 9:23 ` Daniel Vetter
2021-09-14 10:47 ` Laurent Pinchart
2021-09-14 12:58 ` Arnd Bergmann
2021-09-14 19:45 ` Daniel Vetter
2021-09-14 15:43 ` Luck, Tony
2021-09-13 14:52 ` James Bottomley
2021-09-14 13:07 ` Linus Walleij
2021-09-13 14:03 ` Mark Brown
2021-09-12 15:55 ` Laurent Pinchart
2021-09-12 16:43 ` James Bottomley
2021-09-12 16:58 ` Laurent Pinchart
2021-09-12 17:08 ` James Bottomley
2021-09-12 19:52 ` Dave Airlie
2021-09-12 7:46 ` Mauro Carvalho Chehab
2021-09-12 8:00 ` Leon Romanovsky [this message]
2021-09-12 14:53 ` Laurent Pinchart
2021-09-12 15:41 ` Mauro Carvalho Chehab
2021-09-10 23:46 ` Laurent Pinchart
2021-09-11 0:38 ` Mauro Carvalho Chehab
2021-09-11 9:27 ` Laurent Pinchart
2021-09-11 22:33 ` Mauro Carvalho Chehab
2021-09-13 12:04 ` Mark Brown
2021-09-12 19:13 ` Dave Airlie
2021-09-12 19:48 ` Laurent Pinchart
2021-09-13 2:26 ` Dave Airlie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YT2zryAKHc/5R2IH@unreal \
--to=leon@kernel.org \
--cc=corbet@lwn.net \
--cc=josh@joshtriplett.org \
--cc=ksummit@lists.linux.dev \
--cc=laurent.pinchart@ideasonboard.com \
--cc=mchehab@kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).