←back to thread

Writing a basic Linux device driver when you know nothing about Linux drivers

(crescentro.se)
496 points sbt567 | 3 comments | 22 Jun 25 10:29 UTC | HN request time: 0.615s | source
Show context
fithisux ◴[26 Jun 25 07:20 UTC] No.44385013[source]▶
There are many innovative OSes that are killed by the lack of Device Drivers.

As a community we must find a way for tackling this issue.

Micro-Kernels are a solution where one can run different OSes but they will reuse the same device driver servers.

But it requires co-ordination and determination.

Rust can be a solution for sure.

replies(2): >>44385177 #>>44387854 #
jeroenhd ◴[26 Jun 25 07:53 UTC] No.44385177[source]▶
Any programming language can be a solution, the programming language itself isn't the problem. Convincing device driver programmers around the world to come up with a universal API that includes all the possible features and works on every OS is.

In this case, the cross-platform libusb should make this code work on either Linux or Windows (if you install the signed Windows drivers). If other operating systems port libusb, they get this code for free.

Most "real" drivers still run in kernel mode, though, and not even Linux can keep their ABI stable (Windows has to, between releases, with the aid of compatibility wrappers that only work for a certain amount of releases).

It would probably be worth it more forbBespoke operating systems to implement either the Windows API (like ReactOS does) or the Linux API (pick an LTS version) to get existing drivers to work. Unless you pay them, most driver programmers aren't going to bother with anything than Windows, maybe Linux, possibly macOS.

replies(2): >>44387342 #>>44393867 #
1. sumtechguy ◴[26 Jun 25 13:43 UTC] No.44387342[source]▶
On a previous project I spent a lot of time trying to figure out a 'generic device driver'. That is actually a decently hard space to crack. As each device has randomly different ways of talking. Some are serial/local bus. Some are memory space. Some have a combination. Some systems broadcast data, some you have to query it, some you have to query then wait for the next broadcast. Some systems mildly follow the spec, some strictly follow it, some strictly follow their own flavor of the spec or an outdated one, some have their totally made up spec that they may or may not give you. Even from the same company you can have two models that on the outside if you use their stuff looks the same but under the hood is sorta different enough that your driver is garbage. I basically ended up here https://xkcd.com/927/
replies(1): >>44393857 #
2. fithisux ◴[27 Jun 25 05:09 UTC] No.44393857[source]▶
The XKCD is wrong in the microkernel concept since the micro-kernel translates the

NxM problem to N+M.

But I agree, that vendors do not make it easy to foster new OSes.

replies(1): >>44396905 #
3. sumtechguy ◴[27 Jun 25 14:05 UTC] No.44396905[source]▶
I just ended up there because I ended up with yet another 'standard' that wraps the wildly different 'APIs' that devices present to the OS.

I set it up so the application layer could just say 'I want to change/get some datapoint'. But the underside of that the 'datapoint' object had to know quite a bit about what to feed into the system to bind up things correctly to do that data transfer. Last time I looked home assistant had something similar to what I was coming up with. I just could not get it to not have a leaky abstraction. The problem was one system might have a set of 16 bit address spaces. While the next one would be 8 bit, the next one would be 78 bit. Then properly decoding those things was also leaky. As many of these systems will do things like bit masking/shifting to pull data out partiular fields. Plus some systems are just simple memory read/writes and others are bind out an RS232 port and fill out this packet just right (dont forget the correct baud rates), oh and there are 6 other things packed into the return packet. The real painful ones were the vendors who got tricky with a DRM handshake before each call and a simple decode system.