USB for Software Developers: An introduction to writing userspace USB drivers
1–10 of 57 posts
Re: USB for Software Developers: An introduction to writing userspace USB drivers
#2But this kinda expects that your USB driver is the application code too, no? This is less of a driver and more of a library + program. If I have, say, a USB to Ethernet device, how do I hook this into the ethernet adapter subsystem?
Re: USB for Software Developers: An introduction to writing userspace USB drivers
#3But this kinda expects that your USB driver is the application code too, no? This is less of a driver and more of a library + program. If I have, say, a USB to Ethernet device, how do I hook this into the ethernet adapter subsystem?
On Linux you could create a tun/tap device from your application and translate data sent over that to requests sent to the ethernet adapter.
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.
Re: USB for Software Developers: An introduction to writing userspace USB drivers
#4[dead]
Re: USB for Software Developers: An introduction to writing userspace USB drivers
#5But this kinda expects that your USB driver is the application code too, no? This is less of a driver and more of a library + program. If I have, say, a USB to Ethernet device, how do I hook this into the ethernet adapter subsystem?
Things which are relatively standard tend to get good generic support: Ethernet devices will generally be USB/CDC/ECM or RNDIS, for example. That may Just Work (tm) if it has the right descriptors.
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)
Re: USB for Software Developers: An introduction to writing userspace USB drivers
#6But this kinda expects that your USB driver is the application code too, no? This is less of a driver and more of a library + program. If I have, say, a USB to Ethernet device, how do I hook this into the ethernet adapter subsystem?
On Linux you could create a tun/tap device from your application and translate data sent over that to requests sent to the ethernet adapter. 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.
Not to be too facetious but a great place for communicating with the kernel where there are a ton of other driver subsystems is... the kernel.
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.
Re: USB for Software Developers: An introduction to writing userspace USB drivers
#7Earlier quoted context omitted.
On Linux you could create a tun/tap device from your application and translate data sent over that to requests sent to the ethernet adapter. 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.
Not to be too facetious but a great place for communicating with the kernel where there are a ton of other driver subsystems is... the kernel. 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'…
In HFT user-space networking drivers have a long history - there is too much latency induced by switching from kernel to user space to handle networking.
> 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...
Re: USB for Software Developers: An introduction to writing userspace USB drivers
#8But this kinda expects that your USB driver is the application code too, no? This is less of a driver and more of a library + program. If I have, say, a USB to Ethernet device, how do I hook this into the ethernet adapter subsystem?
Things which are relatively standard tend to get good generic support: Ethernet devices will generally be USB/CDC/ECM or RNDIS, for example. That may Just Work (tm) if it has the right descriptors. 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 p…
DFU - great example. If you have a USB device that has a DFU class that needs a custom driver, can dfu-util and the like hook into these userspace drivers? Or do you also need to maintain the application part?
Re: USB for Software Developers: An introduction to writing userspace USB drivers
#9Earlier quoted context omitted.
On Linux you could create a tun/tap device from your application and translate data sent over that to requests sent to the ethernet adapter. 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.
Not to be too facetious but a great place for communicating with the kernel where there are a ton of other driver subsystems is... the kernel. 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'…
Arguably all these other subsystems shouldn't be in the Kernel either but that's a different topic :)
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
Re: USB for Software Developers: An introduction to writing userspace USB drivers
#10Earlier quoted context omitted.
Things which are relatively standard tend to get good generic support: Ethernet devices will generally be USB/CDC/ECM or RNDIS, for example. That may Just Work (tm) if it has the right descriptors. 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 p…
DFU - great example. If you have a USB device that has a DFU class that needs a custom driver, can dfu-util and the like hook into these userspace drivers? Or do you also need to maintain the application part?
dfu-util actually also just uses libusb under the hood!
Any class or device that doesn't have a driver baked into the OS can be implemented like this. And if you'd need the DFU functionality in a different application, you may be able to just simply link parts of the dfu-util tool into your application