I wish there was a nice wrapper dedicated to abstracting hardware support better so developers can focus on the interesting parts instead of arguing with wi-fi cards.
Not really; also, the freedom to do something "different" in the device driver space is extremely limited: all you can do is decide on the packaging, kernel space vs. userspace and not much more.
So beyond the low level drivers that directly interact with hardware, an OS differs in how you ... drive the drivers. What your HAL looks like, and then what the abstractions above that look like.
It's by that definition that e.g. Android is considered a different OS from GNU/Linux. Same kernel, but the hardware is exposed much differently to end-user applications.
The NetBSD kernel has the ability to be built as a library, letting various drivers be used in other ways -- it's called a "rump kernel" [0]. I've never played with it myself but my understanding is that this would be sufficient to provide drivers in one's own kernel, given enough plumbing and shims and such.
(With enough shims one could borrow drivers from any kernel -- see ndiswrapper to use Windows network-card drivers in Linux -- but the rump kernel scaffolding is supposed to make it easier.)
[0] https://www.netbsd.org/gallery/presentations/justin/2015_Asi...
The University of Utah had a research project back in the late 1990s which offered exactly that – the OSKit project [0]. A set of libraries for common (at the time) x86 hardware so OS developers and researchers could focus on what was original about their OS instead of writing yet another hard disk or Ethernet driver
Unfortunately, the research project ended circa 2000 and it is dead now. No support for contemporary devices like Wifi and USB. But, if you just want something to run in a VM (QEMU or VirtualBox or whatever) it probably still works.
How was OSkit different?
Linux gives no API stability guarantees for its internal APIs, only for the system call interface. By contrast, the OSKit developers intended the API of each component to be a stable documented interface. The Linux developers don't want Linux's internal APIs to be stable documented interfaces because that has a cost in that it slows down refactoring, which in turn reduces the various benefits that refactoring can produce (better performance, better maintainability, new features, etc)
It also has the "benefit" of making it extremely difficult to actually distribute stable device drivers that are closed source, or are simply not part of the actively-maintained kernel source tree.
There is NopSys, about 3500 lines of C and 600 lines of assembler for booting, accessing device registers, and responding to interrupts. So you can write the rest of the OS on top of that. CogNOS is a Smalltalk system written on top of NopSys.
https://github.com/nopsys/nopsys
You bring up wi-fi cards and that is definitely one category of hardware with little standardisation/documentation (I suspect due to FCC regulations and such.) Wired ethernet is a bit better --- Realtek and Intel NICs are both quite well-documented, with the latter being more complex. The other difficult one is GPU acceleration (but a VESA framebuffer is usually available, which gets you at least a GUI if not a fast one.)
Are Linux device drivers not nice enough? Hell, why couldn’t one think, for that matter, of a minimal Linux kernel as some kind of BIOS. Incidentally, we already use it as a hypervisor, so you could probably even include support for the devices you want in the hypervisor itself.
Thinking about it, this is what the BIOS was originally for: to provide a bare minimum abstraction to the hardware. I hoped that UEFI would extend this abstraction in a meaningful way, making OS development easier. Instead it has made it even more complex.
UEFI, sadly, added support for raw x86 option ROMs, to some extent casting us back into the "old" world.
- OO support / modularity
- microkernel
If this decision was made and adhered to early then:
- new drivers could just import and inherit, filling in only the specifics
- new drivers would be self-contained and (hopefully) not affect stability of the system
I guess the problem is that most drivers have already been implemented in C and would require redesign or at least porting.