From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
Jiri Kosina <jikos@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
ksummit@lists.linux.dev, linux-cxl@vger.kernel.org,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?
Date: Thu, 25 Jul 2024 23:07:03 +0300 [thread overview]
Message-ID: <20240725200703.GG14252@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20240725194314.GS3371438@nvidia.com>
Hi Jason,
On Thu, Jul 25, 2024 at 04:43:14PM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 25, 2024 at 10:31:25PM +0300, Laurent Pinchart wrote:
>
> > I don't think those are necessarily relevant examples, as far as device
> > pass-through goes. Vendors have many times reverted to proprietary ways,
> > and they still do, at least in the areas of the kernel I'm most active
> > in. I've seen first hand a large SoC vendor very close to opening a
> > significant part of their camera stack and changing their mind at the
> > last minute when they heard they could possibly merge their code through
> > a different subsystem with a pass-through blank cheque.
>
> If someone came with a fully open source framework for (say) some
> camera,
We have such a framework, it's called libcamera :-) Multiple vendors are
already collaborating.
> with a passthrough kernel driver design, would you reject it
> soley because it is passthrough based and you are scared that
> something else will use it to do something not open source?
It depends what "passthrough kernel driver design" means. If it means
accessing the PCI registers directly from userspace, yes. That's what X
used to do before KMS, and I'm glad it's now a distant past.
If it means a kernel driver that takes the majority of its runtime
parameters from a buffer blob assembled by userspace, while controlling
clocks, power domains and performing basic validation in kernelspace,
then I've already acked multiple drivers with such a design, exactly
because they have open-source userspace that doesn't try to keep many
device features proprietary and usable by closed-source userspace only.
> I wouldn't agree with that position, I think denying users useful open
> source solutions out of fear is not what Linux should be doing.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2024-07-25 20:07 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-08 22:26 Dan Williams
2024-07-09 6:09 ` Christoph Hellwig
2024-07-09 19:43 ` Dan Williams
2024-07-10 13:05 ` Jason Gunthorpe
2024-07-21 18:51 ` Laurent Pinchart
2024-07-22 13:27 ` Jason Gunthorpe
2024-07-09 10:01 ` Greg KH
2024-07-09 12:25 ` Leon Romanovsky
2024-07-09 12:33 ` Greg KH
2024-07-09 12:47 ` Leon Romanovsky
2024-07-11 14:07 ` Jason Gunthorpe
2024-07-09 20:09 ` Dan Williams
2024-07-09 16:02 ` James Bottomley
2024-07-09 22:15 ` Dan Williams
2024-07-10 13:22 ` Jonathan Cameron
2024-07-11 11:00 ` Jonathan Cameron
2024-07-11 15:05 ` Jason Gunthorpe
2024-07-11 17:01 ` Jonathan Cameron
2024-07-11 17:45 ` Jason Gunthorpe
2024-07-11 16:36 ` Dan Williams
2024-07-12 10:37 ` Jonathan Cameron
2024-07-21 19:25 ` Laurent Pinchart
2024-07-22 7:31 ` Leon Romanovsky
2024-07-22 8:53 ` Laurent Pinchart
2024-07-22 10:44 ` Leon Romanovsky
2024-07-22 11:10 ` Laurent Pinchart
2024-07-22 13:28 ` Leon Romanovsky
2024-07-22 14:13 ` Laurent Pinchart
2024-07-22 14:43 ` Jason Gunthorpe
2024-07-22 10:42 ` Ricardo Ribalda Delgado
2024-07-22 11:18 ` Laurent Pinchart
2024-07-22 11:56 ` Ricardo Ribalda Delgado
2024-07-25 20:01 ` Laurent Pinchart
2024-07-26 8:04 ` Ricardo Ribalda Delgado
2024-07-26 10:59 ` Laurent Pinchart
2024-07-26 15:40 ` Ricardo Ribalda Delgado
2024-07-28 17:18 ` Laurent Pinchart
2024-07-29 9:58 ` Ricardo Ribalda Delgado
2024-07-29 10:31 ` Laurent Pinchart
2024-07-31 11:54 ` Sakari Ailus
2024-07-31 13:15 ` Daniel Vetter
2024-08-02 15:07 ` Laurent Pinchart
2024-08-13 10:17 ` Tomasz Figa
2024-08-13 10:26 ` Laurent Pinchart
2024-08-13 10:33 ` Tomasz Figa
2024-08-13 10:58 ` Laurent Pinchart
2024-07-11 13:50 ` Jason Gunthorpe
2024-07-11 15:16 ` James Bottomley
2024-07-11 16:29 ` Jason Gunthorpe
2024-07-23 11:20 ` Jiri Kosina
2024-07-23 11:36 ` James Bottomley
2024-07-23 23:22 ` Jiri Kosina
2024-07-24 20:12 ` James Bottomley
2024-07-24 20:00 ` Laurent Pinchart
2024-07-24 20:37 ` James Bottomley
2024-07-24 21:10 ` Steven Rostedt
2024-07-25 19:31 ` Laurent Pinchart
2024-07-25 19:43 ` Jason Gunthorpe
2024-07-25 20:07 ` Laurent Pinchart [this message]
2024-07-25 23:39 ` Jason Gunthorpe
2024-07-26 8:04 ` Ricardo Ribalda Delgado
2024-07-26 12:49 ` Laurent Pinchart
2024-07-26 13:11 ` Jason Gunthorpe
2024-07-26 14:22 ` Laurent Pinchart
2024-07-26 15:43 ` Ricardo Ribalda Delgado
2024-07-28 15:25 ` Laurent Pinchart
2024-07-29 9:57 ` Ricardo Ribalda Delgado
2024-07-29 14:20 ` Jason Gunthorpe
2024-07-26 8:03 ` Ricardo Ribalda Delgado
2024-07-26 13:22 ` Laurent Pinchart
2024-07-26 15:44 ` Ricardo Ribalda Delgado
2024-07-28 17:02 ` Laurent Pinchart
2024-07-26 16:49 ` James Bottomley
2024-07-28 16:44 ` Laurent Pinchart
2024-07-26 17:33 ` Daniel Vetter
2024-07-29 14:10 ` Jason Gunthorpe
2024-07-25 9:26 ` Ricardo Ribalda Delgado
2024-07-25 10:51 ` Wolfram Sang
2024-07-25 12:23 ` Leon Romanovsky
2024-07-25 13:02 ` Ricardo Ribalda Delgado
2024-07-25 13:20 ` Leon Romanovsky
2024-07-25 13:29 ` Mark Brown
2024-07-25 14:18 ` Leon Romanovsky
2024-07-25 14:22 ` James Bottomley
2024-07-25 17:37 ` Leon Romanovsky
2024-07-26 13:58 ` James Bottomley
2024-07-25 19:42 ` Laurent Pinchart
2024-07-26 8:02 ` Ricardo Ribalda Delgado
2024-07-26 13:11 ` Laurent Pinchart
2024-07-26 15:40 ` Ricardo Ribalda Delgado
2024-07-28 11:23 ` Laurent Pinchart
2024-07-29 9:56 ` Ricardo Ribalda Delgado
2024-07-29 10:38 ` Laurent Pinchart
2024-07-26 16:01 ` James Bottomley
2024-07-26 17:56 ` Laurent Pinchart
2024-07-25 13:44 ` Steven Rostedt
2024-07-26 14:27 ` Laurent Pinchart
2024-07-26 15:34 ` Steven Rostedt
2024-07-28 16:03 ` Laurent Pinchart
2024-07-27 0:16 ` Dan Williams
2024-07-28 11:18 ` Laurent Pinchart
2024-07-28 15:16 ` Greg KH
2024-07-28 15:34 ` Laurent Pinchart
2024-07-28 15:49 ` James Bottomley
2024-07-29 6:10 ` Greg KH
2024-07-31 12:33 ` James Bottomley
2024-07-31 12:45 ` Laurent Pinchart
2024-08-01 14:41 ` Jason Gunthorpe
2024-08-07 0:06 ` Dan Williams
2024-08-07 0:13 ` James Bottomley
2024-08-16 11:12 ` Hannes Reinecke
2024-07-29 14:56 ` Jakub Kicinski
2024-07-29 15:16 ` Greg KH
2024-07-29 15:29 ` Jason Gunthorpe
2024-07-29 12:45 ` Jonathan Cameron
2024-07-29 13:38 ` Borislav Petkov
2024-07-29 14:29 ` Jonathan Cameron
2024-07-29 14:58 ` Jason Gunthorpe
2024-07-30 13:19 ` Borislav Petkov
2024-08-01 14:23 ` Jason Gunthorpe
2024-07-29 15:42 ` Jason Gunthorpe
2024-07-29 22:37 ` Dan Williams
2024-07-30 7:13 ` Daniel Vetter
2024-08-01 14:22 ` Jason Gunthorpe
2024-08-06 7:14 ` Daniel Vetter
2024-08-06 13:04 ` Jason Gunthorpe
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=20240725200703.GG14252@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=dan.j.williams@intel.com \
--cc=jgg@nvidia.com \
--cc=jikos@kernel.org \
--cc=ksummit@lists.linux.dev \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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