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). James
