Message-ID: <20240724200012.GA23293@pendragon.ideasonboard.com>
Date: Wed, 24 Jul 2024 23:00:12 +0300
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: 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 Tue, Jul 23, 2024 at 07:36:24AM -0400, James Bottomley wrote:
> On Tue, 2024-07-23 at 13:20 +0200, Jiri Kosina wrote:
> > On Mon, 8 Jul 2024, Dan Williams wrote:
> > 
> > > 2/ Device passthrough, kernel passing opaque payloads, is already
> > > taken for granted in many subsystems. USB and HID have "raw"
> > > interfaces
> > 
> > Just as a completely random datapoint here: after I implemented
> > hidraw inteface long time ago, I was a little bit hesitant about
> > really merging it, because there was a general fear that this would
> > shatter the HID driver ecosystem, making it difficult for people to
> > find proper drivers  for their devices, etc.
> 
> The problem with hidraw is that userspace has to understand the device
> to use it, but a lot of HID devices (keyboards, mice, serial ports,
> etc.) want to fit into an existing ecosystem so they have to have a
> kernel driver to avoid having to update all the user applications. 
> However, entirely new devices don't have the existing ecosystem
> problem.
> 
> > Turns out that that didn't happen. Drivers for generic devices are
> > still implemented properly in the kernel, and hidraw is mostly used
> > for rather specific, one-off solutions, where the vendor's business
> > plan is "ship this one appliance and forget forever", which doesn't
> > really cause any harm to the whole ecosystem.
> 
> That's not entirely true.  FIDO tokens (the ones Konstantin is
> recommending for kernel.org access) are an entire class of devices that
> use hidraw and don't have a kernel driver.  There's an array of
> manufacturers producing them, but the CTAP specification and its
> conformance is what keeps a single user mode driver (which is now
> present as a separate implementation in all web browsers and the
> userspace libfido2) for all of them.  Fido is definitely not a one off,
> but on the other hand, not having a kernel driver doesn't seem to harm
> the ecosystem and they can get away with it because there was no
> existing device type for them to fit into (except, as you say, an array
> of incompatible and short lived USB key tokens which annoyed everyone
> by having usability limits due to the oneoffness).

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.

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.

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.

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.

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

Powered by blists - more mailing lists