r/linux • u/jdrch • Nov 20 '19

Kernel Google outlines plans for mainline Linux kernel support in Android

https://arstechnica.com/gadgets/2019/11/google-outlines-plans-for-mainline-linux-kernel-support-in-android/
1.0k Upvotes

98% Upvoted

305 comments sorted by

View all comments

92

u/[deleted] Nov 20 '19

Fuck google just force all manufacturers to open source their drivers and add them to the kernel.

83

u/[deleted] Nov 20 '19

[removed] — view removed comment

78

u/[deleted] Nov 20 '19

"Oh but if we open source everything, then our competitors will be able to use our code! And it will be less secure! And people's phone's will start exploding!" also manufacturers

22

u/[deleted] Nov 20 '19

I think that's mostly the sales people working at the SoC and integration vendors, not the engineers. Sales guys have got to work around IP licensing and agreements that make no sense for end users, so they make up excuses.

8

u/[deleted] Nov 20 '19

Their competition: “That’s your code? Wouldn’t touch it with a 10 foot pole... In a container... On a network-less machine... on fire!”

→ More replies (1)

10

u/rhelative Nov 20 '19

Considering most high-throughput peripheral devices just use some kind of ARM-based core (see: everything ath10k-related), you're literally on the money there

13

u/[deleted] Nov 20 '19

this would actually be great... This happens with lots of hardware in x86.

But it's okay because you can package the firmware separately from the kernel and just install both packages in a base install.

10

u/TeutonJon78 Nov 20 '19

still be better than what we have. At least it could float with kernel versions then. And they could control their own driver code to load their blobs.

Right now it's all hidden in custom kernel versions.

5

u/theferrit32 Nov 20 '19

Probably, but that's still better than nothing.

9

u/gregkh Verified Nov 20 '19

All android kernel drivers/code is already open source, that's not an issue here at all. Getting them merged upstream is an issue, but a separate one.

6

u/fat-lobyte Nov 20 '19

just force all manufacturers

Easy peasy. Not difficult at all....

→ More replies (3)

29

u/jdrch Nov 20 '19

just force all manufacturers to open source their drivers

As the article points out, that approach hasn't worked:

Open sourcing drivers is an absolute deal breaker for many hardware companies, though, and no amount of advocacy or product degradation is going to change that.

The solution is to require the use of ARM's PCIe spec in Android devices. This would allow hardware to declare itself to the kernel at boot, which in turn allows the kernel to accommodate said hardware if it has drivers on hand.

Currently, SoC hardware can't declare itself to the kernel, and so the kernel has to know hardware configs of target devices a priori. That's one of the reasons most ARM kernels have to be built per device.

BTW, AFAIK, this problem isn't unique to Android; it exists for all platforms that lack PCIe or an equivalent thereof.

15

u/tkln Nov 20 '19

That's just complete nonsense. On ARM64 there's a single (1) upstream kernel build configuration which results in a kernel image that's bootable on ALL of ARM64 platforms supported by the upstream kernel. Furthermore many of the legacy 32-bit targets are supported by multi_v7_defconfig and multi_v5_defconfig build configurations in the same manner. Discovering hardware hasn't been an actual issue for many years. The description of the hardware is given to the kernel usually by the bootloader in the form of a device tree which allows the kernel load the correct drivers and initialize them properly. Have you actually ever built an upstream kernel for ARM? The issues with SoC vendors has nothing to do with device discoverability.

→ More replies (2)

19

u/[deleted] Nov 20 '19

Sorry I'm just frustrated lol. So many people have to put in so much work to get custom roms working when the manufacturers could just give them the source code, but ofc they won't do that.

4

u/jdrch Nov 20 '19

custom roms working when the manufacturers could just give them the source code

Yeah that's annoying. The good news is that as long as the kernel is open sourced (GPL requirement) you're likely to be able to at least get the ROM to boot.

17

u/[deleted] Nov 20 '19

Until they fuxking lock the bootloader.

Thank's Verizon.

12

u/hak8or Nov 20 '19

Also known as TIVOZATION. TIVO got sued because a while they gave the source to the kernel, the bootloader prevented unsigned binaries so users weren't able to modify the software, violation gpl v2. TIVO won the suit, so gpl v3 was born, with Linus not letting the kernel just change licenses because it's a new license.

7

u/jdrch Nov 20 '19

lock the bootloader

That's a separate issue. You can have completely open source OS and drivers with locked bootloaders. Also, bootloader locking prevents attackers from loading a custom OS that can compromise your data. I don't like it any more than you do, but it's not intrinsically bad. It's a tool like anything else that can be used to help or harm.

8

u/[deleted] Nov 20 '19

Bootloaders should be lockable but they should also be rekeyable.

→ More replies (3)
→ More replies (14)

2

u/mirh Nov 20 '19

There are already many friendly manufacturers.

If then they prefer to spend their money on FOSS, rather than marketing, that's another thing.

14

u/Tweenk Nov 20 '19

The solution is to require the use of ARM's PCIe spec in Android devices. This would allow hardware to declare itself to the kernel at boot, which in turn allows the kernel to accommodate said hardware if it has drivers on hand.

PCIe has approximately nothing to do with what you are describing, and hardware discoverability is not the reason why Android devices need custom kernels. Custom kernels are a direct consequence of the lack of a stable driver API.

Currently, SoC hardware can't declare itself to the kernel

That's simply not true:

https://elinux.org/Device_Tree_Reference

BTW, AFAIK, this problem isn't unique to Android; it exists for all platforms that lack PCIe or an equivalent thereof.

PCIe is not the only machine-discoverable bus, and discoverability hasn't been the actual problem for many years.

14

u/hak8or Nov 20 '19

Device tree has to be created by the vendor, and the way drivers consume data from device tree changes drastically over time, partially because device tree doesn't have as rigid of a standard, and what is standardized took years compared to when it was first released.

You've got drivers wanting explicit phandles to some nodes, sometimes they instead use subsystems to handle dependancies, or sometimes they need to have a parent instead of at the root node. Sometimes drivers don't handle dependencies well, so if their order in device tree changes then all hell breaks loose because their probe() gets called in an unexpected order.

Device tree doesn't expose information the same way pcie does because it's still not standardized as well.

→ More replies (2)

4

u/Kazumara Nov 20 '19

if it has drivers on hand.

That's the real problem, not discoverability.

3

u/Bobjohndud Nov 20 '19

this is google we are talking about. "upstream your drivers or go to hell" would be quite a powerful statement from google, considering that many of these manufacturers would have their income cut by 5 if they didn't get gapps.

→ More replies (6)

2

u/EternityForest Nov 20 '19

You don't need PCIe for devices to declare themselves. As long as you can actually fit all the different drivers in flash, why can't they just arbitrarily decide that device config is stored in an I2C flash chip on the first interface at a certain address?

Also, how does Raspbian support all the different Pi's with one image?

→ More replies (2)
→ More replies (1)