Comment by apatheticonion
10 months ago
Does Linux have the ability to load drivers dynamically (like Windows)? Is there a reason why developers don't develop drivers outside of the kernel and have users simply install them post-install?
10 months ago
Does Linux have the ability to load drivers dynamically (like Windows)? Is there a reason why developers don't develop drivers outside of the kernel and have users simply install them post-install?
Yes, it technically does (kernel modules), but the difference between Linux and NT is that Microsoft guarantees (as much as possible) that its ABIs are stable whereas Linux explicitly does not preserve backwards compatibility in the kernel (only the userspace is the stable interface).
EDIT: Reading this: https://www.kernel.org/doc/Documentation/process/stable-api-...
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).
> It seems like a huge technical factor holding back a stable ABI is the C compiler itself.
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!
DrillShopper has already posted (https://youtu.be/MShbP3OpASA?si=GJ1_0B81b7bFY_iZ&t=2890) says a lot of things.
It can, but Linux does not have a stable driver ABI. Whoever wrote the out-of-tree drivers would have to constantly update them whenever there was a breaking change to the kernel, which I understand is relatively common.
That's interesting. Dumb question but why doesn't Linux aim for a stable driver ABI? Does it impede delivery speed?
I think nvidia uses out-of-tree drivers that are dynamically loaded - does that mean that nvidia drivers are tied to specific kernel versions?
The rationale for not having a stable driver ABI is here: https://www.kernel.org/doc/Documentation/process/stable-api-...
RE: nvidia - yes
nvidia uses "DKMS" to rebuild itself for each running kernel.
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 reply →
Yes, it can load drivers dynamically.
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.
To my knowledge, out-of-tree drivers are quite inconvenient to maintain compared to in-tree drivers, due to the kernel's unstable API (a driver that works on a given version of the kernel likely only works on that single version unless it has lots of ifdefs to handle all the other versions).