Comment by roblabla
5 years ago
Linux drivers don't have a fixed ABI (or even API), making such a feat somewhere between hard and impossible. You'd have to constantly play catch up with the latest kernel refactorings, which would require a tremendous amount of engineering effort.
Heck, it'd probably be easier to emulate the Windows driver architecture - at least those have proper ABI compat.
I asked this question during the recent Linux kernel plumbers conference: "How often in practice do the kernel A{B,P}Is fro device drivers change ?". I got a very mixed response.
My take away was that while 'new' driver classes/subsystems do involve more churn in the core kernel support subsystems, there is a clear trend towards convergence in terms of significant change.
If the change truly was significant and continuous then that would impede productisation with the Rust kernel. I'm not saying that the A{B,P}Is are in any way stable but I personally don't think that keeping up will be an intractable problem.
In the spirit of Kerla's authors prime motive - which appears to be hacking for knowledge - this might be something to try, perhaps with a driver class that is known to be more stable.
FreeBSD’s linuxkpi - bits and pieces of Linux KAPI provided to make porting Linux drivers to FreeBSD easier - works just fine, so this assumption is wrong.
>Heck, it'd probably be easier to emulate the Windows driver architecture - at least those have proper ABI compat.
And better drivers.
Actually many Linux drivers are far better than their Windows counterparts - many Windows drivers are complete shit. It is entirely dependant on your particular hardware. I know the driver for my WiFi in my laptop is far crappier in Windows for example.