In theory, writing a Linux device driver shouldn’t be that hard, but it is harder than it looks. However, using libusb, you can easily deal with USB devices from user space, which, for many purposes, is fine. [Crescentrose] didn’t know anything about writing user-space USB drivers until they wrote one and documented it for us. Oh, the code is in Rust, for which there aren’t as many examples.
The device in question was a USB hub with some extra lights and gadgets. So the real issue, it seems to us, wasn’t the code, but figuring out the protocol and the USB stack. The post covers that, too, explaining configurations, interfaces, and endpoints.
There are other ancillary topics, too, like setting up udev. This lets you load things when a USB device (or something else) plugs in.
Of course, you came for the main code. The Rust program is fairly straightforward once you have the preliminaries out of the way. The libusb library helps a lot. By the end, the code kicks off some threads, handles interrupts, and does other device-driver-like things.
So if you like Rust and you ever thought about a user space device driver for a USB device, this is your chance to see it done. It didn’t take years. However, you can do a lot in user space.
Oh, okay. For a sec I thought Linux was ported to run on an USB hub.
And there is still people that insists on that Linux is monolitic… 😝
https://en.wikipedia.org/wiki/Linux_kernel?useskin=vector
Saying the Linux kernel isn’t monolithic seems even more wrong?!
Reminds me of the diagnostic tool Nvidia uses for all of its testing and debugging. It is called MODS which either stands for “MOdular Diagnostic System” or “MOnolithic Diagnostic System” depending on who you ask.
I consider it an hybrid kernel, because it allows to create device drivers in user space too (you can create character and block devices, use FUSE for file systems, libusb for usb devices… And what is more important: they are being used a lot). Also, the trend is to move to user space as much as possible.
This definition is misleading. TLDR; the line is very blurry and getting moreso over time
The meat of the microkernel vs monolithic kernel comparison is about two things: Running software in protected mode, leveraging hardware supported privilege models, and running drivers and kernel extensions outside of kernel memory in user space privilege levels.
In practice there are a lot of issues with this definition when it comes to Linux, which has always run in protected mode and drivers have always been modular.
While it’s technically correct to say that Linux uses a monolithic kernel, and a driver can cause a kernel fault, nearly all system services run in user space, an increasing number of drivers run in user space, drivers aren’t allowed to corrupt user space, and there are kernel level memory protections. On top of this, virtualization allows for containerised access to physical hardware that can’t cause a kernel fault.
In practice this means Linux on servers doesn’t suffer any issues related to monolithic design, and desktop Linux users pretty much only have problems with video card drivers crashing, which can sometimes be recovered from.
Well, to me Linux is the monolith.
https://www.youtube.com/watch?v=b75EpoF1W88&t=210s
The black monolith? I’m not clicking on that.
A quick read, looks pretty easy, I like it!
I’ve had great experiences with the
nusbcreate which, unlikerusbmentioned in the article, does not use libusb. This frees one from having to manage distribution of the libusb shared library.I did something similar when I “smarted up” a laptop cooler. I even ended up creating idiomatic integrations between libusb’s async interface and Rust async. My driver is also a system tray and all of it, including the UI, runs in a single thread. This is the project, if anyone is interested: https://github.com/bobozaur/cooler-than-you