6 ms·

What I don't understand (due to my ignorance, please explain if you can)... what keeps the driver blobs from continuing to work from one version of Android to t

What I don't understand (due to my ignorance, please explain if you can)... what keeps the driver blobs from continuing to work from one version of Android to the next? 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?

detaro 6y ago
With new Android versions come new kernel versions, and the interfaces to drivers are not stable, and I assume Android-specific interfaces also do change.
deleted 6y ago
[deleted]
pantalaimon 6y ago
Are you implying the 'no stable binary ABI' policy is responsible for a lot of e-waste?
- cwyers 6y ago
  I mean, that seems to be the result, yes? The intent is to compel device manufacturers to release the source of their drivers, but at this point, I think we have to admit that's not a great description of what's happening in the mobile space.
  - DaiPlusPlus 6y ago
    > The intent is to compel device manufacturers to release the source of their drivers 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.
    - dathinab 6y ago
      > 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.
      - cwyers 6y ago
        Why? WDDM drivers written for Windows Vista can still work on Windows 10. And Windows is not a "niche" system.
        dathinab 6y ago
        Because Windows is a (very broken) Micro-Kernel system which did very little changes to it's kernel (as far as I know) in the last many years, in difference to that Linux is a macro kernel with constant changes and improvements to it. 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.
        DaiPlusPlus 6y ago
        Windows NT is not a microkernel - Windows CE was, however. 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.
  - admax88q 6y ago
    I dunno, seems a stretch to blame the kernel for e-waste when theres tons of other well funded parties creating the waste in the first place with zero intention of supporting the device beyond a year, let alone enabling anyone else to support it. The android ecosystem is already better than the completely proprietary feature phones of before.
  - AnthonyMouse 6y ago
    > The intent is to compel device manufacturers to release the source of their drivers, but at this point, I think we have to admit that's not a great description of what's happening in the mobile space. 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.
- imtringued 6y ago
  No, Qualcomm is responsible for that. It's their device. The idea that a third party is responsible for supporting thousands of different devices simply doesn't make sense.
bri3d 6y ago
This is because the Linux kernel itself is constructed and developed in a way where driver interfaces (API) are ruthlessly refactored and the linker interface for kernel modules (ABI) is intentionally version-incompatible. If the driver's source code is not in the kernel, it doesn't gain the benefit of kernel developers doing this ruthless refactoring and falls behind immediately from a source point of view, and from a binary point of view, modules compiled for one kernel intentionally will not work with another. 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.
- baybal2 6y ago
  > 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 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.
  - dathinab 6y ago
    Or you just push it upstream, which solves your problem because whoever is refactoring kernel code is also likely doing the appropriate changes in your code if necessarily.
    - cwyers 6y ago
      This assumes that the person making the SoC owns all the rights to the code for their drivers, instead of licensing them from other firms.

detaro 6y ago

With new Android versions come new kernel versions, and the interfaces to drivers are not stable, and I assume Android-specific interfaces also do change.

deleted 6y ago

[deleted]

pantalaimon 6y ago

Are you implying the 'no stable binary ABI' policy is responsible for a lot of e-waste?

cwyers 6y ago
I mean, that seems to be the result, yes? The intent is to compel device manufacturers to release the source of their drivers, but at this point, I think we have to admit that's not a great description of what's happening in the mobile space.
- DaiPlusPlus 6y ago
  > The intent is to compel device manufacturers to release the source of their drivers 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.
  - dathinab 6y ago
    > 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.
    - cwyers 6y ago
      Why? WDDM drivers written for Windows Vista can still work on Windows 10. And Windows is not a "niche" system.
      - dathinab 6y ago
        Because Windows is a (very broken) Micro-Kernel system which did very little changes to it's kernel (as far as I know) in the last many years, in difference to that Linux is a macro kernel with constant changes and improvements to it. 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.
        DaiPlusPlus 6y ago
        Windows NT is not a microkernel - Windows CE was, however. 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.
- admax88q 6y ago
  I dunno, seems a stretch to blame the kernel for e-waste when theres tons of other well funded parties creating the waste in the first place with zero intention of supporting the device beyond a year, let alone enabling anyone else to support it. The android ecosystem is already better than the completely proprietary feature phones of before.
- AnthonyMouse 6y ago
  > The intent is to compel device manufacturers to release the source of their drivers, but at this point, I think we have to admit that's not a great description of what's happening in the mobile space. 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.
imtringued 6y ago
No, Qualcomm is responsible for that. It's their device. The idea that a third party is responsible for supporting thousands of different devices simply doesn't make sense.

bri3d 6y ago

This is because the Linux kernel itself is constructed and developed in a way where driver interfaces (API) are ruthlessly refactored and the linker interface for kernel modules (ABI) is intentionally version-incompatible. If the driver's source code is not in the kernel, it doesn't gain the benefit of kernel developers doing this ruthless refactoring and falls behind immediately from a source point of view, and from a binary point of view, modules compiled for one kernel intentionally will not work with another. 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.

baybal2 6y ago
> 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 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.
- dathinab 6y ago
  Or you just push it upstream, which solves your problem because whoever is refactoring kernel code is also likely doing the appropriate changes in your code if necessarily.
  - cwyers 6y ago
    This assumes that the person making the SoC owns all the rights to the code for their drivers, instead of licensing them from other firms.