Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

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

On Fri, Jul 26, 2024 at 10:04:48AM +0200, Ricardo Ribalda Delgado wrote:
> On Thu, Jul 25, 2024 at 10:07 PM Laurent Pinchart wrote:
> > 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.
> 
> Nobody has suggested giving PCI register access to userspace.

I know you didn't, but as I didn't expect Jason to be familiar with the
camera ISP discussions, I didn't want to make any specific assumption
regarding what he meant by passthrough kernel driver design.

> > 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.
> 
> If that was an option we would not be having this discussion.
> 
> Vendors cannot have vendor access in v4l2.
> """
> It is not an option to upstream a driver that has support for
> undocumented closed features. Basically maintainers can't put their
> name on something that contains unverifiable (for them) and unusable
> (by all except the vendor) features.
> """
> https://linuxtv.org/news.php?entry=2022-11-14-1.hverkuil

What is not an option exactly in my description above ? We have multiple
V4L2 drivers for ISPs. They receive ISP parameters from userspace
through a data buffer. It's not allowed to be opaque, but it doesn't
prevent vendor closed-source userspace implementations with additional
*camera* features, as long as the *hardware* features are available to
everybody.

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