Bringing the Android kernel back to the mainline [LWN.net]

Bringing the Android kernel back to the mainline

Posted Nov 17, 2018 11:22 UTC (Sat) by kugel (subscriber, #70540)
Parent article: Bringing the Android kernel back to the mainline

> This design will clearly not eliminate the out-of-tree code problem, since those modules will, in many or most cases, not come from the mainline. But there is still a significant change here: vendor-specific code will be relegated to loadable modules and, thus, be unable to change the core kernel.

Doesn't that mean that it'll become impossible to replace the running kernel because the binary-only modules are going to depend in them? And it will promote binary-only modules even more.

Not sure this is an improvement from a POV of users that want to run their own kernel/ROMs on Android devices.

to post comments

Bringing the Android kernel back to the mainline

Posted Nov 17, 2018 13:35 UTC (Sat) by excors (subscriber, #95769) [Link]

Modules != binary-only modules. Binary-only modules are probably GPL violations and (as far as I've seen) are pretty rare.

I think it's trying to address the problem where the vendor provides a tarball with full kernel source code, but it includes e.g. large invasive changes to the scheduler code to support big.LITTLE or whatever, which makes it nearly impossible to port to a new kernel version. Google is saying that vendors shouldn't make any changes to the core code, their changes should all be split into modules with well-defined interfaces. (Not necessarily stable interfaces - they might only work with a single kernel version - but that still makes it much easier to port to a newer kernel.) (Obviously they still need to release the source for these modules.)

Presumably any invasive changes the SoC vendors want will have to be developed and pushed upstream a couple of years before they want to ship products with it, to give time for multiple rounds of reviews and testing and fixes before it ends up in a stable release that gets picked for Google's next generic system image that is used for the conformance tests on those products before they're released. Then once the products are released, they can finally tell whether the patches they designed a couple of years earlier actually work (in terms of improving the user experience, and in terms of not having one-in-a-million bugs that were impossible for QA to find but happen lots when you've got ten million users).

That sounds rather impractical, unless the hardware stagnates and doesn't need major new features any more, so I assume what would actually happen is that vendors will make their device work just well enough on the generic kernel to pass Google's conformance tests, without caring about performance or power efficiency or any optional features, and then replace it with an invasively hacked kernel for their shipped product. But at least it does push them towards minimising invasive changes when they can.