7 ms·

As long as Linus refuses to provide a stable driver API, this won’t happen. OEMs will only pay to write custom drivers for a SoC once, and that means you’ll be

As long as Linus refuses to provide a stable driver API, this won’t happen. OEMs will only pay to write custom drivers for a SoC once, and that means you’ll be stuck with one kernel (or any binary-compatible version). Every device requires entirely custom drivers for this, because ARM has no device enumeration. Until Torvalds finally stops being so stubborn on this, Android and IoT devices will have such a short lifetime, and people will have to continue backporting fixes to ancient kernels.

wbl 9y ago
Or they could put drivers in that are upstreamable.
- kuschku 9y ago
  That’s not easily possible – most ARM SoCs have no device enumeration, so you need to hardcode the memory addresses and physical ports of everything. These are different for every single chip. EDIT: yes, some problems are now solved with Device Tree, but from my experience building Android ROMs, that doesn't solve half of the problems (as many SoCs have special custom hardware, too)
  - kelnos 9y ago
    Isn't that what devie-tree and those dts/dtb/dto files starting to appear under the arch/arm/ tree in the kernel source are meant to address?
  - theatrus2 9y ago
    This is what DeviceTree solves. Not using DeviceTree now for SoC drivers is just pure laziness. https://elinux.org/Device_Tree_Reference https://elinux.org/Device_Tree_Reference
    - kuschku 9y ago
      Well, Device Tree solves some of the issues, but sadly not all of them. A more stable ABI would certainly help a lot.
cmurf 9y ago
Is it all that unreasonable? I don't see that Google's Zircon kernel has API guarantees either, but as the driver model doesn't require mainlining, it suggests the code can remain under wraps and ostensibly kernel specific.
- throwawaysml 9y ago
  If Zircon is a proper microkernel system, then it ought to have such guarantees. But it's too early to tell anything about Zircon and at what end of the microkernel spectrum it will land.
greenhouse_gas 9y ago
Does FreeBSD or NetBSD have a stable ABI?
- throwawaysml 9y ago
  FreeBSD has a stable kernel ABI for each release and is allowed to break it in a new version. This allows nVidia to have an easier time providing binary drivers on FreeBSD.
- artificial 9y ago
  Yes, especially for the y part of X.y. [1] Although since version 7 multiple symbols are supported. [2] If you're interested in what the release engineering team has to say about it this page [3] contains more details. [1] https://wiki.freebsd.org/Releng/ABI https://wiki.freebsd.org/Releng/ABI [2] https://wiki.freebsd.org/BinaryCompatibility https://wiki.freebsd.org/BinaryCompatibility [3] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-releng/article.html https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd...
- pjmlp 9y ago
  Yes, the *BSDs, all proprietary UNIX variants, Windows, mainframes and pretty most everyone else with exception of Linux.
- kev009 9y ago
  The kernel ABI is stable between major version numbers. It is never intentionally broken between majors. More importantly, the kernel APIs are very stable, which seems to be intentionally broken on Linux regularly. Userland ABI is much more stringent, pretty much any commercially used OS will maintain compatibility for old applications indefinitely, Linux and Free and Net BSD included.
  - tosstossy 9y ago
    > which seems to be intentionally broken on Linux regularly Please provide evidence to back the claim of intent. This comes across as if you're implying malice, when it's far more likely interfaces change in the natural course of development where there are no restraints like abi/api stability commitments.
dankohn1 9y ago
I wrote this explanation for the intentional lack of a stable device driver API a decade ago, and it’s still relevant today: https://www.linuxfoundation.org/publications/the-linux-driver-model-a-better-way-to-support-devices/ https://www.linuxfoundation.org/publications/the-linux-drive...
- kuschku 9y ago
  That’s an explanation, but doesn’t fix the very real issues. We have a situation today where nvidia works better on Linux than AMD, even though AMD open sourced their entire base driver, and only wants to provide a few modules as proprietary additions (such as an implementation of 3D screenshots as Ansel competitor), because the kernel maintainers refuse to allow any stable ABI in the kernel. And this is just stubborn, and doesn’t help at all. If this mindset continues, we continue to be stuck with drivers being proprietary DKMS modules. Already today I have to build dozens of proprietary DKMS modules into my kernel all the time, and recompilation times are horrible.
  - colemannugent 9y ago
    I think you're confusing performance with ease of use. Top of the line Nvidia hardware beats AMD hardware. As much as I hate to admit it, nvidia's cards perform better across all platforms leading me to believe that they have a real hardware advantage. Nvidia's cards perform better on Linux than AMD, which I would argue is because Nvidia has more money to throw at the problem. If the issue was the non-stable kernel ABI, then Nvidia surely would be affected in exactly the same way. AMD cards have more of the "Just Works" thing going for them that Dan mentioned in his article. In terms of ease of use I can't imagine it getting much easier than the driver you need being mainlined. What I really liked about Dan's article was this bit: In Linux, hardware support only gets better; it never gets worse.
    - kuschku 9y ago
      But that's not the case. AMDGPU with mesa on any distro I've tried leads to crashes in mesa, it leads to OpenGL not working, and nothing running. The mainline driver is useless, the average result is "the color of a television tuned to a dead channel". AMDs AMDGPU-PRO proprietary solution at least works sometimes. In contrast, NVIDIAs proprietary driver always simply works.

wbl 9y ago

Or they could put drivers in that are upstreamable.

kuschku 9y ago
That’s not easily possible – most ARM SoCs have no device enumeration, so you need to hardcode the memory addresses and physical ports of everything. These are different for every single chip. EDIT: yes, some problems are now solved with Device Tree, but from my experience building Android ROMs, that doesn't solve half of the problems (as many SoCs have special custom hardware, too)
- kelnos 9y ago
  Isn't that what devie-tree and those dts/dtb/dto files starting to appear under the arch/arm/ tree in the kernel source are meant to address?
- theatrus2 9y ago
  This is what DeviceTree solves. Not using DeviceTree now for SoC drivers is just pure laziness. https://elinux.org/Device_Tree_Reference https://elinux.org/Device_Tree_Reference
  - kuschku 9y ago
    Well, Device Tree solves some of the issues, but sadly not all of them. A more stable ABI would certainly help a lot.

cmurf 9y ago

Is it all that unreasonable? I don't see that Google's Zircon kernel has API guarantees either, but as the driver model doesn't require mainlining, it suggests the code can remain under wraps and ostensibly kernel specific.

throwawaysml 9y ago
If Zircon is a proper microkernel system, then it ought to have such guarantees. But it's too early to tell anything about Zircon and at what end of the microkernel spectrum it will land.

greenhouse_gas 9y ago

Does FreeBSD or NetBSD have a stable ABI?

throwawaysml 9y ago
FreeBSD has a stable kernel ABI for each release and is allowed to break it in a new version. This allows nVidia to have an easier time providing binary drivers on FreeBSD.
artificial 9y ago
Yes, especially for the y part of X.y. [1] Although since version 7 multiple symbols are supported. [2] If you're interested in what the release engineering team has to say about it this page [3] contains more details. [1] https://wiki.freebsd.org/Releng/ABI https://wiki.freebsd.org/Releng/ABI [2] https://wiki.freebsd.org/BinaryCompatibility https://wiki.freebsd.org/BinaryCompatibility [3] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-releng/article.html https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd...
pjmlp 9y ago
Yes, the *BSDs, all proprietary UNIX variants, Windows, mainframes and pretty most everyone else with exception of Linux.
kev009 9y ago
The kernel ABI is stable between major version numbers. It is never intentionally broken between majors. More importantly, the kernel APIs are very stable, which seems to be intentionally broken on Linux regularly. Userland ABI is much more stringent, pretty much any commercially used OS will maintain compatibility for old applications indefinitely, Linux and Free and Net BSD included.
- tosstossy 9y ago
  > which seems to be intentionally broken on Linux regularly Please provide evidence to back the claim of intent. This comes across as if you're implying malice, when it's far more likely interfaces change in the natural course of development where there are no restraints like abi/api stability commitments.

dankohn1 9y ago

I wrote this explanation for the intentional lack of a stable device driver API a decade ago, and it’s still relevant today: https://www.linuxfoundation.org/publications/the-linux-driver-model-a-better-way-to-support-devices/ https://www.linuxfoundation.org/publications/the-linux-drive...

kuschku 9y ago
That’s an explanation, but doesn’t fix the very real issues. We have a situation today where nvidia works better on Linux than AMD, even though AMD open sourced their entire base driver, and only wants to provide a few modules as proprietary additions (such as an implementation of 3D screenshots as Ansel competitor), because the kernel maintainers refuse to allow any stable ABI in the kernel. And this is just stubborn, and doesn’t help at all. If this mindset continues, we continue to be stuck with drivers being proprietary DKMS modules. Already today I have to build dozens of proprietary DKMS modules into my kernel all the time, and recompilation times are horrible.
- colemannugent 9y ago
  I think you're confusing performance with ease of use. Top of the line Nvidia hardware beats AMD hardware. As much as I hate to admit it, nvidia's cards perform better across all platforms leading me to believe that they have a real hardware advantage. Nvidia's cards perform better on Linux than AMD, which I would argue is because Nvidia has more money to throw at the problem. If the issue was the non-stable kernel ABI, then Nvidia surely would be affected in exactly the same way. AMD cards have more of the "Just Works" thing going for them that Dan mentioned in his article. In terms of ease of use I can't imagine it getting much easier than the driver you need being mainlined. What I really liked about Dan's article was this bit: In Linux, hardware support only gets better; it never gets worse.
  - kuschku 9y ago
    But that's not the case. AMDGPU with mesa on any distro I've tried leads to crashes in mesa, it leads to OpenGL not working, and nothing running. The mainline driver is useless, the average result is "the color of a television tuned to a dead channel". AMDs AMDGPU-PRO proprietary solution at least works sometimes. In contrast, NVIDIAs proprietary driver always simply works.