[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
Newer testing version: here

For Testing Only!: http://d-h.st/5JE2

I've merged in all applicable commits from both the linux kernel mainline 3.18.y LTS updates branch, and also (more experimentally) all the applicable commits from android kernel common for 3.18

There's a lot going on. The kernel appears to work, but I need to have a good look through the commits to make sure everything I've applied was sensible, and also give it a good testing to ensure nothing is broken. Watch out for kernel Oopses, these will manifest as a sudden reboot.

It's interesting to note that back five years ago we couldn't merge in LTS patches so confidently as android wasn't accepted into the mainline kernel. Fortunately it is now, and has been for a good length of time, so patches are quite likely to apply cleanly without breaking anything. However, since we pull from kernel source modified by OnePlus, we inevitably encounter some code that has been altered already.

My approach to code conflict is to defer to the OnePlus changes. I cherry-pick my way through the individual commits using a script and automatically abandon any patches that conflict with the OnePlus source.

It's also interesting to note that a great deal of patches don't have any impact on code that is actually built for our device, since the full linux kernel source supports many architectures and devices that have nothing to do with our device. However I still bring these commits in since subsequent patches that will affect our code may rely on earlier patches that had nothing to do with our device's code!

Here's some useful commands for helping to understand the changes brought in from other sources in large batches:

find . -name '*.o'
git diff --stat c9d75816a8b1118452926b3455f56418a703d1d1..HEAD

First you list all of the .o files, which are the objects build by the compiler from the actual .c code files that we require for a kernel that works on our device. The second line produces an output like this:

arch/arc/Makefile | 1 -
arch/arc/include/asm/entry.h | 17 ++--
arch/arc/include/asm/irqflags.h | 2 +-
arch/arc/include/uapi/asm/elf.h | 11 +-
arch/arc/kernel/arcksyms.c | 2 +
arch/arc/kernel/asm-offsets.c | 2 +
arch/arc/kernel/process.c | 2 +-
arch/arc/kernel/setup.c | 6 +-
arch/arc/kernel/stacktrace.c | 2 +-
arch/arc/mm/cache_arc700.c | 9 ++
arch/arm/Makefile | 8 ++
arch/arm/boot/dts/armada-375.dtsi | 2 +-
arch/arm/boot/dts/dra7.dtsi | 71 +++++++++++++
arch/arm/boot/dts/imx25-pdk.dts | 5 +-
...etc...

...that shows us which files have been changed by the patches from a certain point (c9d7581 is after I'd applied all of the mainline patches, but before I'd started patching from android-kernel-common), up to 'HEAD' which is the latest commit. You can then use a tool like MS Excel to compare the two lists and see what's changed in just the files in our device's kernel. It's the same as the overlapping bit in a Venn diagram!

So, using this method I've worked out the details of this epic code cherry-pick. From the linux mainline we have 30794 lines of code changed, of which:

code	removed	added
OP3	11.8%	14.2%
N.A	28.0%	46.0%

From the android-kernel-common repo we have 28216 lines of code changed, of which:

code	removed	added
OP3	12.0%	21.0%
N.A	5.6%	61.5%

It's also interesting to observe that although the mainline has patched a higher volume of code, the amount that is applicable to the device we're building for is about 15% less than kernel-common has provided (8000 lines vs 9300 lines). It's usual for code to grow slightly over time too, as more comprehensive safety checks and features are brought in. Often too, more efficient algorithms are longer in code length, so sometimes performance improvements result in longer code. Another observation is that the mainline code additions that apply to our device have only caused a total growth of about 740 lines vs kernel-common, which has introduced ~2500 new lines of code. This is as you would expect, since the mainline caters to everyone and has a LTS remit, i.e. to provide stability, whereas android is much more targeted and is always adding new features that require kernel support.

So what were the biggest affected areas from this big patch from kernel-common?

directory	removals	additions
drivers/md	997	1309
fs/ext4	440.75	1163.25
mm	437.25	1064.75
init	13.5	450.5
security/selinux	161	314
drivers/cpufreq	0	54

In my next post I'll provide some additional detail about what changes have been provided in the new code added to these areas of the kernel.