Message-ID: <CAPybu_0SN7m=m=+z5hu_4M+STGh2t0J-hFEmtDTgx6fYWKzk3A@mail.gmail.com>
Date: Thu, 25 Jul 2024 11:26:38 +0200
From: Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: James Bottomley <James.Bottomley@...senpartnership.com>, Jiri Kosina <jikos@...nel.org>, 
	Dan Williams <dan.j.williams@...el.com>, ksummit@...ts.linux.dev, 
	linux-cxl@...r.kernel.org, linux-rdma@...r.kernel.org, netdev@...r.kernel.org, 
	jgg@...dia.com
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

On Wed, Jul 24, 2024 at 10:02 PM Laurent Pinchart
<laurent.pinchart@...asonboard.com> wrote:

>
> While "userspace drivers" often cause allergic reactions, I think I
> won't cause a controversy if I say that we are all used to them in
> certain areas. My heart rate will increase if someone proposes replacing
> a USB webcam driver with a libusb-based solution, but I don't lose sleep
> over the fact that my GPU is mostly controlled by code in Mesa.

I think the key point here is that USB webcams follow a standard, and
GPUs don't.


>
> What I get from the discussions I've followed or partcipated in over the
> years is that the main worry of free software communities is being
> forced to use closed-source userspace components, whether that would be
> to make the device usable at all, or to achieve decent level of
> performance or full feature set. We've been through years of mostly
> closed-source GPU support, of printer "windrivers", and quite a few
> other horrors. The good news is that we've so far overcome lots (most)
> of those challenges. Reverse engineering projects paid off, and so did
> working hand-in-hand with industry actors in multiple ways (both openly
> and behind the scenes). One could then legitimately ask why we're still
> scared.


It would be great to define what are the free software communities
here. Distros and final users are also "free software communities" and
they do not care about niche use cases covered by proprietary
software.
They only care (and should care) about normal workflows.


>
> I can't fully answer that question, but there are two points that I
> think are relevant. Note that due to my background and experience, this
> will be heavily biased towards consumer and embedded hardware, not data
> centre-grade devices. Some technologies from the latter however have a
> tendency to migrate to the former over time, so the distinction isn't
> necessarily as relevant as one may consider.
>
> The first point is that hardware gets more complicated over time, and in
> some markets there's also an increase in the number of vendors and
> devices. There's a perceived (whether true or not) danger that we won't
> be able to keep up with just reverse engineering and a development model
> relying on hobyists. Getting vendors involved is important if we want to
> scale.

If we want vendors involved, we need to build an ecosystem where they
feel invited.

We should not take as hostages our users and impose rules on how they
should build or even sell their product.

>
> Second, I think there's a fear of regression. For some categories of
> devices, we have made slow but real progress to try and convince the
> industry to be more open. This sometimes took a decade of work,
> patiently building bridges and creating ecosystems brick by brick. Some
> of those ecosystems are sturdy, some not so. Giving pass-through a blank
> check will likely have very different effects in different areas. I
> don't personally believe it will shatter everything, but I'm convinced
> it carries risk in areas where cooperation with vendors is in its
> infancy or is fragile for any other reason.

We control what is accepted and what is not. We just need clear rules,
to avoid regressions like:
- For areas where there is a standard (NVME, UVC,...) most of the
drivers must be in-kernel, and use generic system calls.
- For areas with no standard, custom system calls are allowed, and
some part of the driver can be in userspace.
- To land a driver, there must be a full open source stack capable of
using it for standard use cases.
- If there is an established open source stack (mesa, openVINO,
libcamera...), the open source stack must be based on it.
- Vendor passthrough mechanisms are allowed for niche use cases or
development/experimentation.

I believe those rules are already in place in some subsystems. We just
have to agree what rules should apply to all the kernel by policy.

We can agree that this kind of discussion is done better face to face.

Regards!



>
> Finally, let's not forget that pass-through APIs are not an all or
> nothing option. To cite that example only, DRM requires GPU drivers to
> have an open-source userspace implementation to merge the kernel driver,
> and the same subsystems strongly pushes for API standardization for
> display controllers. We can set different rules for different cases.
>
> --
> Regards,
>
> Laurent Pinchart
>


--
Ricardo Ribalda

Powered by blists - more mailing lists