There's an existing out-of-tree Linux driver¹ that looks promising, but AFAICT it only does the bare minimum of exposing the MIDI ports for use with e.g. JACK, and it's also unclear how stable it is and whether it really does support the XT (the README says the kernel panic got fixed, but there are open issues about it; the README says the XT's supported, but there are open issues about that, too). I'd like to be able to create new routing presets and stuff like what the proprietary companion app can do, and I'd also like to be able to use the thing without needing to shove extra drivers into my kernel, and I'd also like to be able to use the thing on my OpenBSD and Haiku boxen, so I've been perusing LibUSB docs since a userspace USB driver that then presents the relevant MIDI ports and some tooling to reroute the MIDI ports as desired seems like something useful. This article happens to be exactly what I've been looking for w.r.t. a starting point for such a userspace driver.
----
I use this to access UVC devices correspondingly without cgo: https://github.com/kevmo314/go-uvc
The userland approach is much more useful for weird or custom devices. In particular, on Windows you can do one of these user space "drivers" without having to bother with driver signing, and if you use libusb it will be portable too.
(I maintain a small USB DFU based tool for work)
Of course, when you're doing these things in userspace you either need some way of communicating with the Kernel or for the other subsystems to be in userspace as well.
Possibly a good addition to the article would be parallel development of an lkm. I guess it wouldn't have that windows interop but I would also be interested to see how this driver would be implemented on Windows. If it's idk 10x as many lines in the kernel vs userspace, that's a great benefit to the userspace approach.
Worth noting that, this approach is limitted on newer macOS systems: can't build libusb "userspace USB drivers" for devices that are supported by macOS. Without manually disabling some Security features, can't override drivers for system-recognized USB devices.
Sounds like USB is a wonderful standard. Am I wrong?
The device descriptor is easy enough to get right as it doesn't have too many fields and every USB class just defines in the specification which Class and SubClass it uses for its interface descriptor as well as which endpoints that interface needs to have. And that's, for the most part, all you need for the host to recognize your device
auto main() -> int {
int main() {I don't think anyone uses the "native" usb way on either windows or mac os, when it's so much easier to go through libusb.
I've personally done a custom DFU updater for Mac OS some time ago by using libusb. It worked just fine(tm). I don't want to try and evaluate how long it would have taken to do it with the mac api.
Hand it back, with a request to prove that it can't be done with one of the devices that the OS's already recognize as virtual COM ports.
It's not easy to set up a fake or "remapped" USB device on most OS as far as I'm aware, if you were trying to write an adapter program that modified USB packets.
template <typename A, typename B>
auto multiply(A a, B b) -> decltype(a * b) {
return a * b;
}
> OpenOnload: A user-space network stack that intercepts socket calls to bypass the kernel network stack, accelerating standard socket operations for faster networking.
> Netmap: A framework providing a simple API for high-speed packet I/O in user space, bypassing much of the kernel overhead for efficient packet forwarding and filtering.
https://dysnix.com/blog/high-frequency-trading-infrastructur...
Much easier to design the device to avoid that. E.g. by abusing USB-HID. The desktop USB missile launcher toy is USB HID, for example.
There are quite a few benefits to doing these things in userspace over the Kernel, not really necessarily just because of the code size:
- The code is much easier to write and debug, you just write code like you always would.
- Bugs don't have the possibility to taking down your entire system or introduce vulnerabilities
- Especially on Windows, everyone can do this without requiring an impossible to get driver signing certificate