WerWolv

My goal was primarily to be able to get the game to run as easily as possible, without having to fiddle around with CD emulators and other stuff.

Basically just running an exe file and be done. This also allowed me to put the game on one of my Android Handhelds in the end! All these games are surprisingly touchscreen friendly :)

It tends to be vendor drivers / vendor patches. Getting frustrated that my changes aren't applied just to see that the vendor decided to hardcode a field or dynamically patch the device tree in undocumented ways is what usually gets me

This is a valid point a friend brought up as well. There's no reason all of this is enabled except for keeping the config simple. I only recently learned about `make tinyconfig` though which should let you creating a absolutely minimal config to start off of. I might add that as a note at the end

Great read, thanks! What was used to make these Signal diagrams? They look really great

WebUSB works in pretty much the same way. You'll have the same set of functions that libusb exposes there too.

Sadly it's not supported at all on anything but Chrome right now

Descriptors also were kind of a mystery for me until I realized that they're just a binary structure with a fixed format that the host reads and interprets.

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

ADB uses libusb or WinUSB directly from userspace too yeah. On Windows you still need a .inf driver though because the WinUSB driver isn't getting loaded by default for Android devices because they're lacking the MS OS Descriptor

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

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

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.