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
