I can't imagine fixing all this without a UART debug console.
Good thing I have this before I got myself a 8g1/8+g1 phone.
Conversation
Being able to boot off from a Google-provided generic kernel and having it (almost) fully functional is incredibly amazing and interesting, but I'm not sure if the custom kernel community will be around anymore if this trend continues.
1
2
25
I don't blame Google for this. If anything, reducing kernel fragmentation was long overdue.
Just wished if they've added another test/certification to ensure everything works when all modules are built-in.
As it stands right now, GKI 2.0 is a nightmare to debug.
2
1
28
Replying to
We stopped building in all the kernel modules for even though we gained a security feature from it (finer grained CFI) because we decided that it's going to become too impractical and benefits of being able to easily update GKI and reuse it across phones are higher.
1
2
We've been updating the GKI code every month to the first stable tag they make in the monthly branches and relying on ABI compatibility to keep it working. Pixel 6 stock OS has been sticking to a monthly branch and only switching at quarterly releases. Easy way to ship sooner.
1
2
It's much easier to maintain kernels with AOSP build system and AOSP manifest system. Too many drivers make assumptions about only being a dynamic kernel module and having their firmware available immediately along with other issues. We got tired of investing resources into it.
1
2
I imagine ROM-side development stuffs wouldn't be affected much.
I was talking about kernel hackers who want to dive into individual device drivers as well as the core kernel code. GKI isn't helping in this regard.
1
1
It's certainly much harder to build everything within the kernel source tree especially with building all the modules into the kernel.
It's a lot nicer when doing things their way since you can maintain a cross-device GKI and easily update it beyond the device kernel versions.
1
2
If you need to change a bunch of those out-of-tree drivers, then you'll need a bunch of additional forks, but it's easy to manage that with scripting. It ends up being easier in a lot of ways regardless.
I can see how it'd be a huge problem if you don't ship those OS images.
1
2
As part of moving to Android 13, which is close to finished, we ended up switching to AOSP build system and dynamic kernel modules for 4th and 5th generation Pixels too simply because we have to use it going forward on 6th gen and beyond and even without GKIs it's much easier.
2
2
There was yet another issue with building in all the modules on the Pixel 5 and it ended up being the catalyst for migrating 4th/5th gen away from in-tree builds with all the modules built into the kernels. It just got too tiring always having to fix those premature init bugs.
We have to port a MASSIVE amount of stuff overall and we don't actually have that many changes to kernel for Pixels right now but major OS releases and even quarterly releases were often ending up with a substantial amount of time spent dealing with bugs with built-in modules.
1
2
When we added 6th gen Pixel support, it was very clear that because of GKIs it was going to be ridiculously hard to do things with our old approach. There are some people maintaining that for those devices but we can't afford to delay even major updates more than a few days.
2