5 ms·
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 h
by timschmidt 2y ago
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.
- prosody 2y agoIsn’t that significantly on the Linux kernel not having stable driver ABIs?
- timschmidt 2y agoI 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.
- gf000 2y agoThey 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.
- realusername 2y agoThey could also contribute to the Linux kernel like normal companies instead of shipping half broken binary blobs.
- IshKebab 2y agoThat'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.
- realusername 2y agoThere'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.
- IshKebab 2y ago> 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.
- gf000 2y agoMost of them buy parts from other companies, that often license the source only for inclusion. This is a very myopic view of the industry.
- realusername 2y agoI'm also saying the industry is broken, I'm well aware that the whole industry isn't really good enough on the software side.
- AnssiH 2y agoAFAIK the Android binary blobs are generally userspace, not kernel drivers.
- asveikau 2y agoI 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.
- byw 2y agoAny devices that fare better in this regard?
- pimeys 2y agoNot 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.
- b9b10eb736 2y agoNobody'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.
- timschumi 2y agoThe 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.
- biorach 2y agoIs 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?
- timschumi 2y agoThe 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.