So, I keep hearing that “Oh, but desktop Linux will never fly without a (stable) driver ABI interface for the Kernel”. At the same time Linux supports the absolutely most hardware out there out of all the subsystems, and seems to be absolutely thriving.
So, speaking from a newbie driver developer perspective, is this really true? What would a stable driver ABI bring to the table, and what is wrong with what we have now? Forgive my ignorance on the matter. 
If the claim is being made somewhere that windows offers “kernel abi compatibility” among its versions, in practice that is untrue. While there are two major windows kernel frameworks, even if the APIs themselves didn’t change between, the component subsystems undergo significant changes. Just to figure out what is going on in the windows kernel among the various releases I have 5 kernel books (3 physical and 2 in pdf) and 8 internals books (7 physical and 1 in pdf).
In practice hardware breaks all the time on windows on account of device driver compatibility due to changes in the underlying components and APIs. If those things so frequently change, ABI compatibility is meaningless.
On the other hand, I have 3 linux books. Only one of which is dedicated to the kernel:
the other two are userland references:
And I am far more confident I understand what a linux system is doing than a windows system.
Why the disparity in quantity of reference material?
I think the open nature of linux makes possible things like strace and ftrace or to grep through the actual source material in extreme cases. So you don’t have to rely on 3rd hand references. Which makes development and maintenance fundamentally easier.
Checked builds and some userland symbols do not lend themselves to the same capabilities; and, in practice, any “abi compatibility” windows claims is fiction.
Need is a strong word.
I would say it definitely helps
Right now any third party driver needs to be recompiled.
Third party commercial drivers may include code under incompatible license and that means that software either becomes unavailable or someone needs to make a shim.
Rather than just having a stable interface.
Fact is, I can download say an NVIDIA driver or VMware workstation and install it on any windows platform from the past 7+ years.
Linux? Need to break out the compiler. Also need to make sure the shim has caught up to the new kernel version.
Yeah, but after doing some research, here is the true kicker.
Windows - You have a single kernel for Windows 7, and one for Windows 10.
Linux - Every distribution have their own kernel. Every single one. That is tens of thousands of different incompatible kernels spread across hundreds of distros for various versions Ubuntu alone has at least 40 different kernels available right now (actively supported).
It is simply not possible to keep binary compatibility with that in any meaningful way.
Yes there is. FreeBSD managed to load windows network drivers for example.
It’s entirely possible but Linux is just ABI hostile.
FreeBSD is one BSD distribution with major releases every couple of years, and yes you can do it for a single distribution - but it will be incompatible with, say, OpenBSD or OSX. Linux also managed to do that network loader, see ndiswrapper. Nowadays you hardly need it anymore though since hardware support has gotten so good.
It is possible to create binary hooks for specific drivers, and it is possible to provide an ABI, sure. Keeping that stable though, that is nigh impossible with the way the kernel devs roll.
I still fail to see what a driver ABI would provide though that cannot be worked around.
My point was that FreeBSD were able to load Windows NDIS drivers into a totally different platform because the Windows drivers conformed to a stable ABI.
If there was no stable ABI for the drivers, that solution would not work.
The ability to load third party, signed drivers without needing to recompile a shim from source every time you run a new kernel. Or alternatively download a new driver for every damn kernel upgrade that was compiled against your vendor’s kernel.
Can that be worked around? Sure, we all do it. But it is a pain in the arse and just one more hoop to jump through because “reasons” that do not exist on other platforms.
Yes, open drivers in-tree are the solution, but we aren’t there yet, and it’s only been what… 25+ years at this point.
Which class of drivers would you say still aren’t there though? For a lot of hardware hardware (not all, but most of it), this is already a reality:
And so on. Most of it (again, not all, but most) works out of the box no fuss no buzz. It’s pretty much nVidia that is the only thing preventing this to become reality.
Its definitely a lot better than it used to be, but its still broken because…
i went looking a few times in the past year in order to “buy linux friendly hardware” and it appears that nobody bothers to maintain a hardware compatibility list any more.
As it happens i lucked out and my X470 Taichi works out of the box, but it was a roll of the dice.
