Most users are on a more substantially modified downstream fork of a longterm branch that's at least 1-2 years old. Most distributions take many weeks or months to ship the longterm updates if at all. There's near zero quality control for kernel.org releases...
Conversation
So now we are talking about gregkh instead of Linus who is cutting the releases. Those details are important, but not to the point that I think was making.
1
The mainline releases are largely only relevant to upstream kernel developers and the longterm releases are relevant to downstream kernel developers. Barely anyone is building and using those directly.
Changes are usually made/shipped downstream before incorporated upstream too.
2
1
It often takes 1-2 years to get support for new hardware upstream even with the vendor doing it. Most things are really developed and shipped downstream, even as out-of-tree modules, before eventually ending up upstream. Changes flow in multiple directions and it's very complex.
1
For an example that's important to me, Clang-compiled kernels with LTO and CFI have been shipped since 2018 on Pixel phones. Support for this still isn't in mainline despite many years of them trying to land it. It's strange seeing people talk about that as if it's bleeding edge.
1
2
At this point, I don't think it's the case that most Linux kernel development is done upstream first. Most people have given up on doing that a long time ago. You get what you need working downstream, ship it, and maybe you try to upstream it but it'll take years to see benefits.
1
Here at AWS, in recent times for features like Nitro Enclaves and Elastic Fabric Adapter getting changes upstream was a launch gating milestone.
Elastic Network Adapter, being "just" a NIC driver, was briefly only available out of tree.
I think "upstream first" is still needed.
1
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.
1
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.
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
Show replies