Comment by bri3d | Hacker News Reader

Comment by bri3d | Hacker News Reader

Parent Full thread

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.

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.

>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.

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.

How is it clear?

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.

Because of this unsubstantiated and baseless claim:

> Support a stable kernel API probably wouldn't be that expensive

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.

This seems like a win-win. The kernel developers are free to refactor as they need to keep the quality and velocity high and companies are incentivized to upstream patches including making drivers in-kernel.

> 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-no...

> 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.

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.

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.

You can demand those terms when you negotiate the license.

And they can say "no" or "money please."

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?

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

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).

Still not as a bad as Linuxant: https://lwn.net/Articles/82305/

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.

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

Reply on news.ycombinator.com