Hacker News Reader

Comment by timschmidt | Hacker News Reader

Often device drivers specific to the model of handset are only available as pre-compiled binary blobs, and will not run with any future kernel release without herculean effort to reverse engineer them and implement a shim. This effectively ties the hardware to a single kernel release.

The practice makes ewaste of otherwise perfectly usable devices, and should be illegal.

View on HN

Any devices that fare better in this regard?

Not really, no. For manufacturers it is faster to just write the drivers once for their chip, and release them targeting to an exact Linux kernel version rather than actually writing good enough code that it goes through the LKML process and gets merged into mainline. It costs money to update the drivers later on and it especially costs money to mainline them later on.

Nobody's asking for mainline submissions though. Just publishing the drivers source code under a FLOSS licence when they stop supporting it would be enough to let the community take over the maintenance.

The kernel side of drivers is already published under a FLOSS license, it's just that the code quality is usually subpar and the important changes are crammed into a tarball together with (sometimes) millions of other lines of changed code.

The sources for the matching userspace binaries (which are usually the issue for Android version bumps) are usually under NDA by the component manufacturer and can not be released by the OEM independently.

Is the kennel driver code not available for the Community to take over the process of mainlining? If that gets done then surely the user-side code will work with all future kennels that contain the driver?

The user-side will work with all kernels that contain the matching driver, but the user-side will not necessarily work on future Android versions without modification.

Isn’t that significantly on the Linux kernel not having stable driver ABIs?

I don't see how any choice the Linux developers make forces phone manufacturers to do anything.

It's their choice to use Linux. They can abide by the license or not ship Linux.

Not to mention that there are many more or less stable APIs within the kernel (which even has versioned API support in places) such as Video4Linux which manufacturers seem dead set against using.

They do abide by the license, but it's also their choice whether to maintain cheap firmware for n years old devices, that they may not even have the license to distribute in source form.

Nonetheless, android mostly solved the issue of the kernel's lack of stable interface via their HAL.

They could also contribute to the Linux kernel like normal companies instead of shipping half broken binary blobs.

That's a really backwards way of thinking about software distribution. It's like Debian's idea that every piece of software in existence should be packaged for Debian (and Suse, Red Hat, Fedora, Ubuntu, etc.).

I don't package any of the software I write for Debian because I don't want to have to jump through their hoops. I don't blame device manufacturers for wanting to avoid jumping through Linux's hoops. Especially with having to deal with Linus.

Nobody likes Apple's app review process do they? I don't think device driver writers should have to go through that.

(I also wish they would open the code but not having a stable driver ABI clearly doesn't make that happen.)

I think a valid reason for not having a stable driver ABI is that it's a mountain of work and makes everything else more difficult. But I've never heard anyone give that as the reason.

There's a big difference between Apple's review process which I would qualify as unnecessary and unfair and Linux's review process which is necessary to produce high quality software.

But it's true that they could at least start by publishing the source code, even if they don't contribute directly.

As for the ABI, I also agree, this would just make the situation worse.

> Linux's review process which is necessary to produce high quality software.

Why? I don't see how that follows. It might be likely to produce better software simply by having experienced kernel devs review the code, but it's definitely not necessary.

Most of them buy parts from other companies, that often license the source only for inclusion.

This is a very myopic view of the industry.

I'm also saying the industry is broken, I'm well aware that the whole industry isn't really good enough on the software side.

AFAIK the Android binary blobs are generally userspace, not kernel drivers.

I think the interfaces we are talking about are not part of upstream Linux. They will bolt on half baked stuff regardless of the interfaces Linux provides.

Reply on news.ycombinator.com