GNU/Hurd Continues Effort To Use NetBSD's Drivers For Better Hardware Support

[sinepgib]

I've always wondered if it would be possible to abstract driver development in a way where the definition of how some hardware worked let multiple operating systems generate or build drivers from them. I know it's far-fetched, but it feels like so many alternative OS projects get stuck in a spot where they only have a handful of drivers, limiting uptake.

I think there's an incentive problem there. You could technically make such a layer I think, but it would mainly benefit fringe OSes at the cost of lost flexibility in development in the bigger ones, as well as extra overhead. Why would the bigger OSes choose to do that, if they pretty much have a net loss with no win. And if the big ones don't do that, then the only ones following the standard are the ones with too low man power to actually implement a significant number of drivers.

[mangeek]

I think there's an incentive problem there.

I'm not hip enough to understand the internals well-enough, but I suspected as much. Perhaps alternative OS providers could build their internal device class subsystems to be somewhat close to Linux ones, since that's the center of mass? At least then they only have to re-invent 20% of the wheel. Are the parts of Linux that implement the device classes for drivers nice and clean?

[sinepgib]

I'm not hip enough to understand the internals well-enough, but I suspected as much. Perhaps alternative OS providers could build their internal device class subsystems to be somewhat close to Linux ones, since that's the center of mass? At least then they only have to re-invent 20% of the wheel. Are the parts of Linux that implement the device classes for drivers nice and clean?

It depends on what we call nice and clean, but the elephant in the room is that they're moving targets. That's what I meant by flexibility in part, when you standardize across implementations you need to freeze stuff in time, regardless of how correct or efficient the choices you made at that moment are. Interfaces in Linux change over time for drivers and other kernel parts.
Besides, a standard tends to become a least common denominator. For example, would you expect all smaller OSes to implement io_uring or an equivalent? AFAICT it's rather pervasive and at some level it may end up affecting some drivers. I know that's true for AF_XDP sockets as well, even tho there's a generic skbuf implementation for it. It'd still be kinda defining the whole architecture of your network stack, which some might find undesirable (for example, how zerocopy sniffing works in Linux is incompatible with how it works on FreeBSD because of this kind of design choices, and both make sense and are different trade offs).
If you make those a requirement then smaller OSes will have a hard time implementing the required features. If they're extensions then you may find that either some drivers don't work out of the box or driver providers restrict to the more limited version instead of taking full advantage of the hardware.