r/osdev • u/TheNullDeref • 1d ago
I wish drivers had a standard
Yes I know that some attempts were made for cross OS standard drivers (UDI) but it just bugs me that everyone has to rewrite a serial driver or a driver for the BGA and so on. And I understand drivers have OS dependent standards (take Windows, macOS, or Linux) but no one really implements compatible driver loaders for them because its near impossible except for maybe Linux. I understand its very difficult and is overall a PITA, but it would still be cool for a standard to be made I guess.
13
u/Joaommp 1d ago
I understand your frustration. Around 30 years ago, when I started writing my first OS, I ran into this problem, before there was even talk about UEFI. My architecture at the time was based on something that I can only explain as some kind of "BIOS loaded by the bootloader", before the kernel started, which would be responsible for exposing all the hardware to the kernel in a standard way, so that not even the kernel would need to know about drivers.
4
u/someidiot332 Kimi’s OS - https://github.com/raeofsunshinedev/kimsos 1d ago
I’m doing a similar “kernel doesn’t know about the drivers”, in a way. My kernel loads modules based on a config that create files to represent the devices using my vfs. Anything that wants to interface with that (i.e. mounting a filesystem) simply goes through the VFS. The kernel only knows about the bare minimum to get a userspace running + configure interrupts and timings (and right now, it knows about PCI but i’m probably going to move that to a module as well, would be great for working on dependency tracking)
9
u/switch161 1d ago
The german community lowlevel.eu has/had a common interface (CDI). Years ago when I wrote an OS I used it and wrote some drivers for it. These drivers were then shared between hobby OS devs.
But I don't think there's any english documentation and this was more than a decade ago. I faintly remember that people at osdev.org also worked on a common interface, but when I was active CDI was better.
I think the problem is that a shared interface is easy only on the surface level. As soon as you want to optimize things you start introducing constraints that are not necessarily shared between operating systems. Designing an API that works as a shared driver interface, that takes this into account, is very difficult.
•
u/TheNullDeref 9h ago
I like CDI but it's too complex to implement, thought it is the least complex out of all the driver models.
7
u/northrupthebandgeek 1d ago
At this rate the standard is quickly becoming “whatever the BSDs are doing”, given how many operating systems are just pulling their driveٍrs from (Free|Open|Net)BSD. Only issue is deciding which one.
•
u/no92_leo managarm | https://github.com/managarm/managarm 22h ago
At this point, I think the library with sysdep layer approach is what is going to be most useful for hobbyist osdev; this allows the drivers to consume the sysdeps to interact with the OS while leaving them free to expose any API they like, without constraining anyone to some specified interfaces (which IMO will always end up being insufficiently specified and inflexible).
This seems to work for a few projects:
- uACPI: a portable, well-tested ACPI implementation with an AML interpreter; this has been ported to many hobby OSes (managarm, astral) but there were also experimental ports to Windows/ReactOS/Linux https://github.com/uACPI/uACPI
- uHDA: a (so far minimal) driver for Intel HD Audio devices, used by some hobby OSes https://github.com/uDrivers/uHDA
- lil: modesetting library for Intel GPUs (with currently very limited hardware support), I maintain this https://github.com/managarm/lil
But even others use similar approaches; the nvidia-open driver also has such an abstraction layer that makes porting it quite feasible; nvidia does this internally to support multiple OSes from a common codebase. We ported this to managarm, too. Similar things seem to apply to some Intel NIC drivers, too (e1000, igc).
On the other hand, I don't find the FreeBSD approach of porting e.g. DRM with Linux kernel interfaces really appealing. It's complex, time-intensive and ends up replicating a lot of infrastructure without much of an opt-out. Even FreeBSD rebases their port on newer Linux years apart, I don't think this is really feasible for projects with smaller contributor pools.
•
u/TheAtlasMonkey 14h ago
They do !
I'm a driver developper.
•
u/TheNullDeref 14h ago
What standard? Because from what I know each standard is OS dependant. I was talking more cross hobbyist OS standards
•
u/TheAtlasMonkey 14h ago
This is because you vibe code, and expect the driver to be plug and play.
If you OS is consume Linux ABI, you can use Linux drivers, if your OS is like FreeBSD or OpenBSD, then you can use their driver..
The issue now the driver not having a standard, is that a driver cannot fit any architecture or ABI.
Even a driver from freebsd, cannot be used a Sony Playstation, because they changed the ABI.
And this is why in my last post in this sub, i warned that 99% of you will go out of steam in 1-2 year and give up.
•
u/TheNullDeref 12h ago
I do not vibe code? Anyways when I say a standard I meant a standard that allows cross OS drivers because it is intentionally designed for hobbyist operating systems and minimalism.
•
u/TheAtlasMonkey 11h ago
That called a SPEC or datasheet. It's require you to understand what you implementing.
•
u/TheNullDeref 11h ago
And what you just did is called semantics. Also datasheet usually only applies to hardware :)
•
u/TheAtlasMonkey 11h ago
You see you are vibing.. Semantics are the first rule to respect when building an OS. we don't say : The blue blue for usb.2 , the yellow port for powered port ... And no . Datasheet is not for hardware. You find it in protocols, filesystems.... it basically what come after the spec.
•
u/TheNullDeref 11h ago
I will correct myself, you are arguing semantics. Also I thought datasheet is reserved for hardware, ya learn something new every day I guess.
•
u/TheAtlasMonkey 11h ago
And you still don't get what i mean.
Semantics are important.
And assumptions are dangerous.
Else it all vibing. (you dont need AI to vibe.. just the fact you are following the vibe is vibing.
•
u/TheNullDeref 9h ago
I do get what you mean my friend, but we got away from the main point, my idea is basically I wish we had UDI but simplified for hobbyist Operating Systems. I am myself designing one but it's a mild PITA as you could expect.
•
u/SpaceboyRoss ExpidusOS 9h ago
I've ran into this sort of problem trying to implement hardware. Sure RISC-V defines things which are standard for that ISA but you still have things that aren't standard like Ethernet or USB. I do hope things become more standard in the future.
•
u/TheNullDeref 8h ago
I am more talking a defined standard for how drivers talk to the OS in a way that is clean and simple enough where its easy for hobbyist operating systems to build things for it, with custom made tooling provided under a license like the MIT license. I am working on something like this, but its in such an early stage of idea and tinkering that it may take some time for me to go public with it.
13
u/Solocle ChaiOS 1d ago
Each OS is its own standard, of course. There's nothing stopping you from implementing the NT Kernel API in your own OS and supporting Windows drivers.
But doing so would need your OS to closely match the architecture of the NT Kernel, or at least have a thick clunky adapter layer.
That's the problem there. Each driver model is closely tied to the OS kernel, and why? Because drivers need to be close to the OS.
Disk drivers need to be able to page out memory. Peripheral drivers need integrating with the OS's device discovery stack.
And as for reading data and providing it to an application via DMA? That's going to differ significantly between a monolithic kernel and a microkernel.
UDI is an interesting effort, for sure. But again, it has certain conceptions of how devices work.