Adding insult to injury, there are now additional 13 repositories that you'll have to track outside of the kernel's Git repository.
Conversation
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.
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.
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
Show replies