This is a conscious and opinionated strategy on the part of Linux, as an effort to make the cost of keeping drivers closed-source high and the cost of kernel refactoring low. It also has... disadvantages, in the form of a massive wasteland of only-supported-once snapshot-in-time devices. I am sure this comment thread will happy expound on this in great and painful detail.
Secondly, there was an entire effort by Google called "Project Treble" to build a stable Android HAL/ABI over the top of these unstable kernel interfaces. Unfortunately it would/will require essentially an Android-specific rewrite from vendors in order to fully implement, so many drivers are not yet operating in this model.
The issue is that Treble simply shifts the compatibility issues from on from one layer (kernel) to another (Android HAL). There's still a compatibility horizon, because newer Android systems will eventually want to use newer kernel features and HAL APIs which were not present on ancient HALs which have been abandoned by the vendor.
And even if the OS could theoretically maintain backwards compatibility with older HAL APIs for 10 years, in practice the System + HAL combinations which aren't fully tested tend to break for various unforeseen reasons, making it unwise to push OS updates to devices which aren't fully supported by their vendor.
I don't think it is intentional. Linux development is very pragmatic, they just want to have freedom to refactor anything without caring about stable kernel APIs.
> Support a stable kernel API probably wouldn't be that expensive
If anyone wants to read the Linux developers’ explanation directly, here it is:
https://www.kernel.org/doc/html/latest/process/stable-api-no...
And Qualcomm is probably very, very happy with this arrangement. They can put a gazillion devs to maintain their BSPs using any means possible, but a small 2nd tier SoC fabbless don't.
I bet a lot of drivers are just interfacing with a standard serial line which could be done in the stable user space and then exposing the next layer through something like FUSE.
If I understand treble correctly that’s close to what Android is doing, where each HAL can be done in userspace?
Also as far as I remember (I might be wrong) the google HAL isn't a abstraction/redirection in the low level kernel module layer it lives on a higher abstraction level and was meant to make the amount of ways braking less but never planed to add abstractions on top of which you could build a graphics driver or CPU support (which doesn't only affect drivers but potential also kernel compiler time conditional compilations).
When asked about it most kernel developers point to closed-door negotiations that are being kept confidential. Usually also saying "trust us, we know what we are doing, we'll get more source opened our way".
Those who actually try to enforce GPL publically are ignored or shunned, e.g. Harald Welte/LaForge of gpl-violations.org
I doubt that was the "intent"... perhaps a contributory argument in favour of a non-stable ABI, but I understand the reasons are far more pragmatic: maintaining a stable kernel ABI is a lot of work which could have strangled Linux in its early years.
And likely would still do so toady. I mean we are speaking about the kernel internal API (not the syscall API, which is stable).
Even systems which pride themself for internal kernel API stability do change the API every view years, while often having much less internal (feature/platform support) changes then Linux. Furthermore in android Linux LTS versions are often used which do support a long term stable ABI, potentially longer then certain other more niche systems priding themself with long support.
The problem is when a device is sold the kernel (minus back ported security fixes) is often already multiple years old so even if you use a kernel with 7 years longtime support you still have a good chance to run into problem. And supporting any kernel internal API for more then that time is unrealistic.
Are the improvements worth the cost? I don't know. (For server applications likely yes, but for desktop likely not).
What I do know is that there are clear benefits of micro kernel architectures, even if they are kinda messed up (for a micro kernel) hybrids like windows has.
Lastly the way the kernel API's are designed can also make a major difference independent of the rest. Honestly the Linux kernel API feels much more raw then the windows API, but I only have every written a single dummy driver for each platform and that was quite a while ago.
Let's not forget about massive stuff like the whole Windows Subsystem For Linux, which was literally an entire separate process type alongside Win32 processes, with its own set of syscalls etc. Added and then deprecated (and probably eventually removed entirely) over the span of years.
Maintaining a stable kernel ABI is no doubt a big investment, but it's possible and doesn't have much to do with whether your kernel is a microkernel or not. Lots of Windows drivers these days are user-space which helps maintain compatibility and stability.
NT has been shifting towards running more driver-code in user-space, as has macOS as well, especially with UMDF (especially for USB devices) and for graphics drivers, which are historically the #1 cause of BSODs - however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel is still responsible for huge swathes of the computer's functionality. With a true micro-kernel there isn't any third-party code in the kernel space - not even a stub.
I typo'd that - it should be
> however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel isn't still responsible for huge swathes of the computer's functionality
The reason I got them initially is that, some about 2.5y back, they were sold on Aliexpress for 3.50 EUR (~5$) and could do dual-band with at least 40 MHz channels, iirc maybe even 80 MHz on 5GHz. They are just tiny USB-A dongles with a USB 2.0 HighSpeed host interface, but they could do station/softAP/station+softAP, obviously restricted to a single channel.
There's a related issue of a rtl8812-au or rtl8821-au (or compatible) stick (Edimax EW-7822UAC) I got before that, with a USB 3.0 SuperSpeed host interface, intended for trying out a remote radio head point-to-point configuration using polarization-duplex with a recycled satellite-TV dish on each end, as it could do AP-mode on 80 MHz wide channels in the 5 GHz band on Linux, with a 867 Mbit/s link rate (assuming full polarization multiplexing based on the stick's 2x2 MIMO and a circular polarizing feed antenna).
But it's still the thing we want, for that and a lot of other reasons. So presumably what we need to do is find a way to exert more leverage, so that we actually get what we want, instead of folding and letting the bad thing take root forever.
The android ecosystem is already better than the completely proprietary feature phones of before.
What prevents people from using the same drivers for a device on Android 7 and upgrading the OS to 9 or 10? I always understood that drivers would continue to allow the OS to recognize the component that the drivers are for unless something drastically changes on the OS side of things.
Why can't we say "Fuck you, Qualcomm" and continue to use the older drivers for newer OS versions without having to wait for them to officially support it?