Hello...
For the past short while I have been fiddling with something to help me understand USB better. The result was changes to vhci, the virtual HCI driver (that is in NetBSD 10.x and -current, but mostly undocumented) that made it more complete and a USBIP test client. Briefly, vhci is to USB what tap is to ethernet. It provides a way to get USB packets into and out of the system through userland. Couple this with a client that knows how to speak USBIP to a server and you can have physical devices in one place and the client in another as long as your network is fast enough. So, for example, a Xen PV kernel can attach to a umass device (or maybe something else) on my laptop. One may argue that this is all a bad idea, but I won't get into that debate. The concept is used for a number of different reasons including snooping on USB traffic (for example writing a device driver for a device that has poor documentation) and software USB devices (there are software FIDO2 keys, for example). The rabbit hole is that I really did not intend on creating such a thing. I mostly just wanted to learn more about USB. Instead of letting what I have done sit in a local tree I have placed it in: https://www.netbsd.org/~brad/usbip/ There are a bunch of READMEs that explain all of the parts and the code itself (and a tar file that is everything). The test client is probably a large pile of rubbish, but it is just a test. I don't have a huge number of USB devices, but what does appear to work is USB mice and keyboards, umass(4) (including presenting a cd(4) to a Xen PVH guest and burning a disk), axe(4), although I will admit that presenting a NIC device over IP to a VM is a little bit odd (except for the strange use case of making a LAN segment appear in a virtual space, a bilocated LAN segment, perhaps???), uftdi(4) and uplcom(4). What might almost work is ubt(4) and maybe with some help, run(4). Host to device ISOCHRONOUS transfers might be working, but I could not test that well, and device to host ISOCHRONOUS transfers are likely unsupported, so uaudio(4) is a hit or miss and probably a miss. I also messed with adding the modified vhci driver to a SIMH vax, just to see how it might work (it did a bit...). Probably, in its current form and without more testing and work, the vhci driver changes are not ready for commiting to the NetBSD source tree. I won't be working on this again, at least not for a long time as I have run out of gas and it was a bit of a side trail anyway, but can answer any questions someone else might have who wants to take this up. Please read the various READMEs first, however, and expect have kernel crashes. It isn't hard to patch this into a 10.x or -current source tree and if you have a handy MS-WINDOWs or Linux box to run the server on you can try it yourself. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
