4 ms·

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 f

by 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.
    - bluGill 6y ago
      You can demand those terms when you negotiate the license.
      - cwyers 6y ago
        And they can say "no" or "money please."
PixelOfDeath 6y ago
Didn't some Linux maintainers had very clear legal words for NVidia when they tried to make a kernel HAL/ABI?
- dathinab 6y ago
  NoyesNo, Nvidia tried to make a doggy legally questionable workaround for license aspects, so it's not quite the same. 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).
  - koolba 6y ago
    Still not as a bad as Linuxant: https://lwn.net/Articles/82305/ https://lwn.net/Articles/82305/
    - Something1234 6y ago
      I'm having trouble understanding the issue was here. Linuxant produced a module that lied to the kernel about being a non-binary blob. Am I correct, but I'm still having trouble understand how the company survived since they seem to have a website up still.
      - corty 6y ago
        Linux kernel license enforcement is very lax. Most binary blob drivers probably violate GPL in one way or the other, as do the "GPL-condom" half-open-source "drivers" that do most of their stuff in a userspace blob. 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
garaetjjte 6y ago
>as an effort to make the cost of keeping drivers closed-source high 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.
- fakename11 6y ago
  It's somewhat pragmatic for the Linux developers. Support a stable kernel API probably wouldn't be that expensive. It's clearly a political decision against writing close source code that does anything low level.
  - alisonkisk 6y ago
    How is it clear?
  - deleted 6y ago
    [deleted]
  - ClumsyPilot 6y ago
    I am not sure why the comment is being downvoted - thats exactly what it is, a political decision to force companies to produce open drivers.
    - joelellis 6y ago
      Because of this unsubstantiated and baseless claim: > Support a stable kernel API probably wouldn't be that expensive
- young_unixer 6y ago
  Ironically, they care a lot about stability towards user space interfaces, to the point that bugs become features if someone depends on them, but they don't care about driver interfaces being stable.
  - kevincox 6y ago
codewiz 6y ago
Project Treble is already fully supported by Qualcomm and other SoC vendors, that's not the issue. 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.
teddyh 6y ago
> This is a conscious and opinionated strategy on the part of Linux If anyone wants to read the Linux developers’ explanation directly, here it is: https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html https://www.kernel.org/doc/html/latest/process/stable-api-no...
Too 6y ago
Is it truly necessary that all these drivers run in the kernel space? 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?

by bri3d 6y ago

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.
  - bluGill 6y ago
    You can demand those terms when you negotiate the license.
    - cwyers 6y ago
      And they can say "no" or "money please."

PixelOfDeath 6y ago

Didn't some Linux maintainers had very clear legal words for NVidia when they tried to make a kernel HAL/ABI?

dathinab 6y ago
NoyesNo, Nvidia tried to make a doggy legally questionable workaround for license aspects, so it's not quite the same. 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).
- koolba 6y ago
  Still not as a bad as Linuxant: https://lwn.net/Articles/82305/ https://lwn.net/Articles/82305/
  - Something1234 6y ago
    I'm having trouble understanding the issue was here. Linuxant produced a module that lied to the kernel about being a non-binary blob. Am I correct, but I'm still having trouble understand how the company survived since they seem to have a website up still.
    - corty 6y ago
      Linux kernel license enforcement is very lax. Most binary blob drivers probably violate GPL in one way or the other, as do the "GPL-condom" half-open-source "drivers" that do most of their stuff in a userspace blob. 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

garaetjjte 6y ago

>as an effort to make the cost of keeping drivers closed-source high 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.

fakename11 6y ago
It's somewhat pragmatic for the Linux developers. Support a stable kernel API probably wouldn't be that expensive. It's clearly a political decision against writing close source code that does anything low level.
- alisonkisk 6y ago
  How is it clear?
- deleted 6y ago
  [deleted]
- ClumsyPilot 6y ago
  I am not sure why the comment is being downvoted - thats exactly what it is, a political decision to force companies to produce open drivers.
  - joelellis 6y ago
    Because of this unsubstantiated and baseless claim: > Support a stable kernel API probably wouldn't be that expensive
young_unixer 6y ago
Ironically, they care a lot about stability towards user space interfaces, to the point that bugs become features if someone depends on them, but they don't care about driver interfaces being stable.
- kevincox 6y ago

codewiz 6y ago

Project Treble is already fully supported by Qualcomm and other SoC vendors, that's not the issue. 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.

teddyh 6y ago

> This is a conscious and opinionated strategy on the part of Linux If anyone wants to read the Linux developers’ explanation directly, here it is: https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html https://www.kernel.org/doc/html/latest/process/stable-api-no...

Too 6y ago

Is it truly necessary that all these drivers run in the kernel space? 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?