So I spent a week on dealing with Snapdragon 8 Gen 1 and GKI 2.0.
I seriously doubt if there's a custom kernel on any device using Snapdragon 8g1.
There are 375 kernel modules on my 8g1 board and it's split out on multiple different partitions.
Conversation
Adding insult to injury, there are now additional 13 repositories that you'll have to track outside of the kernel's Git repository.
1
1
22
If you want to change it, you'd have to change vendor_boot and vendor partition, which is under the dynamic partition (super), which makes it incredibly harder to modify.
1
1
21
If you want to have everything built-in (which is what I'm trying to do), you'll have to venture through fixing a whole bunch of issues as vendors now no longer test !CONFIG_MODULES.
1
1
16
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.
2
13
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.
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
Show replies