honestly I just find the normal part of the AOSP build system bad enough, the thought of doing something with the kernel instills dread
Conversation
(it's the LineageOS kernel build integration, I have absolutely no idea how it works)
1
1
We use the AOSP way of building it separately and including it in the AOSP build as a prebuilt.
Qualcomm has always included a way to run the kernel build in-tree via a wrapper in each kernel source tree as a hack for development. LineageOS turned that into a generic system.
2
2
I don't like running a totally separate build system within the AOSP build system. It takes a ridiculous amount of time and memory to link the Linux kernel with full LTO and it doesn't use kati so it doesn't handle incremental builds well so I really prefer the AOSP approach.
1
4
Why LTO? Does it have extended hardening properties or is it just 3% optimizing non-bottlenecks?
2
Pixels build the kernels with Clang CFI which requires LTO. If you disable dynamic kernel modules, set -fvisibility=hidden as the default and avoid using ThinLTO, you get much better CFI granularity because it can see that nearly everything can't be indirectly called.
2
3
Stock OS uses dynamic kernel modules in order to have a generic base kernel across phones with device-specific modules loaded from vendor. It also speeds up the boot process because loading the dynamic kernel modules is done asynchronously as part of the event-based init process.
1
1
Qualcomm Atheros Wi-Fi in Snapdragon uses SoftMAC and doesn't really have a Wi-Fi chip but rather it's one of the sandboxed processes on the baseband. It hardly has any functionality in the firmware but rather they implement it all in the kernel driver. It's *really* complex.
1
2
So, thanks to the firmware delegating everything to the kernel, half the kernel ends up being the Wi-Fi driver. They started loading it as a dynamic kernel module to save a lot of time in the initial kernel loading. Gradually moving to a generic base kernel across all phones now.
1
2
It sounds like a nice thing, but we'll still be building specialized kernels, and this is going to make our life a lot harder. We'll have to deal with these modules not having proper support for being built into the kernel. Gets old dealing with this same init issue repeatedly.
1
1
Look forward to being responsible for resolving these kinds of bugs in all of these kernel modules:
github.com/GrapheneOS/dev
github.com/GrapheneOS/dev
github.com/GrapheneOS/dev
... sigh. It will be nice when base kernels are a generic common kernel but... going to be so painful too.