It seems like a huge technical factor holding back a stable ABI is the C compiler itself. Binaries changing between compiler versions and changing with different compiler flags.
So while your code can be written such that it appears to respect the interface of an external library, the underlying binary representation might not line up correctly.
If there is agreement that modularity is good for the kernel but technical limitations prevent that from being a reality - surely the solution is to improve C's interoperability first?
---
I'm not a kernel developer and am probably naive here, but on the surface it feels like offering a stable driver ABI is one possible solution to the rust-in-linux controversy that has lead to so many people exiting kernel development.
I'd imagine if projects like Asahi could simply offer out-of-tree drivers, they wouldn't need to maintain a kernel fork (at least not for drivers) or negotiate with core maintainers (which I understand is stressful).
Might also make it easier for vendors like Qualcomm/Samsung/Nvidia to distribute drivers out-of-tree, perhaps reducing the need for long running Linux forks and allowing devices to update to modern Linux kernels.
As a novice hacker, I'd imagine the ability to reuse proprietary driver blobs would allow distros to be created targeting hardware that was otherwise impossible to access as drivers were hidden behind custom kernel forks (e.g. install mainline Fedora on a Samsung phone, taking the GPU driver from the Samsung build of Android - or OpenWRT on an Android powered portable 5g modem).
Additionally, there is politics in play here. Not the politics that is normally discussed outside of HN, but the politics of having companies (at least) release the detailed specifications of their hardware. I cannot really state authoritatively what the Linux developers think on this side, but Linus brandishing his middle finger to Nvidia (https://youtu.be/MShbP3OpASA?si=GJ1_0B81b7bFY_iZ&t=2890) says a lot of things.
Not really. Every OS has a stable C ABI, otherwise there would be no stable OS API functions and no application plugin APIs. The actual reason seems to be that they simply do not want to commit to a stable ABI/API so they are free to make breaking changes and remove outdated APIs. Fair enough, but don't blame it on the compiler!
I think nvidia uses out-of-tree drivers that are dynamically loaded - does that mean that nvidia drivers are tied to specific kernel versions?
RE: nvidia - yes
Closed source modules like nvidia frequently have a kernel-independent proprietary piece and a kernel-specific (open source) ABI piece. Whenever you upgrade your kernel, DKMS will re-build the kernel-specific shim and re-link the proprietary blob. The result is a .ko tailor made for your running kernel, even though most of the code is in a kernel-independent blob.
[1] https://www.phoronix.com/news/NVIDIA-Exploring-Upstream-KMD
There is a reason why in-tree drivers are preferred, and that's because the Linux driver interface and API changes with kernel API changes. The API is considered unstable in the sense that is it not unchanging.
A driver written for one release of Linux may not work with the next release as the API changes.