I'm heavily focused on smartphones where nearly all the drivers are out-of-tree on launch and slowly trickle into the kernel. Literally a majority of the code is not from kernel.org but will gradually trickle there in the years following the launch of an SoC/device.
Conversation
Embedded and phones are a hot mess. I have been lucky to mostly avoid it.
Android's deep kernel fork didn't help. Hopefully that will continue to improve, but it will take time and effort.
3
Android hasn't had a substantial kernel fork for years. It works with mainline kernels.
SoC vendors take latest LTS branch when developing their SoC, implement all their drivers for it, often with a lot of new/rewritten code rather than it just being a minor port from old code.
1
SoC vendor is the upstream for half of the kernel code used on those devices rather than kernel.org.
When Google says they're moving to upstream first they mean giving up on upstreaming remaining few Android common kernel changes and using inferior hacks or eBPF.
1
They defined a stable ABI for kernel modules and hardware support will be done primarily via out-of-tree modules targeting a stable ABI for an LTS branch. ABI can't be at all stable across LTS versions. They won't convince Linux to do anything like that any time soon.
1
github.com/GrapheneOS/ker (just that, no userspace code was dropped) was replaced with literally thousands of lines of code in userspace across multiple components to dynamically manage eBPF rules. What they mean by upstream first is making about a dozen sacrifices like that.
1
2
A particularly painful example is that they switched from ashmem to memfd despite losing the ability to unpin/pin pages similarly to MEM_RESET and MEM_RESET_UNDO on Linux where you can tell the kernel it can free that memory if there's memory pressure but you can ask for it back.
1
1
This was used by web browsers to implement volatile caching aware of memory pressure on Android as they do on Windows since the kernel takes care of it and purges the caches. No such thing on non-Android Linux and now it will be gone on Android, increasing browser memory use.
1
1
They got close enough to not having any required Android common kernel code for them to decide to make these final dozen sacrifices to be able to directly use kernel.org kernels with backported bug fixes, performance improvements and in some cases actual features.
2
1
It doesn't change that over half of the kernel code comes from the SoC vendor. It's just not going to be part of the core kernel but rather dynamically loaded kernel modules loaded from boot_vendor / vendor with enforced ABI stability between them with similar tooling as Treble.
1
I think getting SoC vendor hardware support upstream is pretty much a lost cause at this point and 6 years of LTS support + Generic Kernel Images + ABI stability for modules is going to massively reinforce it.
I guess Google will upstream everything for their own SoC at least...
I assume the Pixel 6 will have 5 years of support because they can't do 6 without moving to a new LTS kernel and they probably don't want to do that due to the massive amount of regressions. They'll have to figure out a way to cope with it once per phone for longer support.