[Galaxy Note 4 Original Android Development] fattire:
Advantages of kernels...

Well I haven't even looked at the "new" kernel source, but kernels tend to improve over time-- aside from support for more hardware (which wouldn't be too relevant for us), as time passes, potential crashes or other bugs may be fixed, more efficiencies introduced, maybe portions of the kernel are reworked to be better in one way or another, maybe new hardware features are enhanced (finer control over LED colors or brightness for example), maybe new peripherals (samsung introduced a new flip-case with LEDs or something... or some other add on) there may be security holes fixed, or in the case of the selinux support stuff, new safety minimal mechanisms ratcheted up. Since we're building off of Samsung's kernel (which is in turn forked off Qualcomm's "Code Aurora" modified kernel, which is in turn modified from the vanilla linux kernel), at each step improvements are made more-and-more specifically-- For CM we wanted to include some stuff that wasn't included by Samsung, who did include things particular to the hardware that may not have been in Qualcomm's version which had customizations for the apq8080 model of their Qcom system on a chip, that is not in the original Linus Torvald kernel.

As changes "ripple up"-- coming from any of those sources, we only get the latest version from Samsung. So want to re-apply the CM improvements over that... I talked earlier about how Samsung strips out the entire commit history when they provide their kernel source, making it kinda hard to easily search for which contributions in its history have already been applied (did they or did they not include recent change that may impact battery life, for example). You can look at the source itself to see if the changes are there, but not easily search for the commit or do a comparison between histories to see what was added or left out...

This afternoon gekke tried the cm 12.1 kernel w/my additions that had previously not worked with cm13... on cm12. The amazing thing is it did boot, meaning at least that my kernel doesn't BLOCK a boot.... making us now think maybe something in the cm 13 userspace (ie, /system or ramdisk) that isn't set up right... possibly it's the kernel commandline that starts the kernel, which I did change to turn off selinux... maybe that can't be done any more.

So anyway, he's looking into that... we're in different time zones and he's been pretty busy the past few days, so I'm just hanging to see what he reports back. But the great news is he's able to generate a .zip now too, so he can mess with the kernel and userspace too.

For the record, I basically added three things that I was told were needed for M:

SELinux changes -- was told that without them, you get a reboot into recovery, which is indeed what gekke experienced.

vidc changes-- this is a driver change for msm (qcom/code aurora) that has to be made to get Marshmallow to build. Without those commits added, the display HAL breaks with missing symbols. This may be, but I'm not saying it is, related to a video change in M having to do with moving from OpenSSL to BoringSSL (Google's version of OpenSSL). The switch resulted in some symbols in the adreno blobs no longer appearing. Now that I think about it, it's probably not that. But anyway, as I mentioned in a previous post, there is a workaround for this issue that is temporary until we get some new adreno blobs with the right symbols.

uid_cputime -- "Per-UID cpu time statistics" this a wholly new feature that M uses apparently. Apparently it "lists the total utime and stime for the active as well as terminated processes for each of the uids." In the past, new kernel features were needed to be added to the kernel, such as in Ice Cream Sandwich (I think? Jellybean maybe?) when Settings would show you how much mobile/wifi network traffic you were using. Being able to do this needed a kernel feature that had to be backported to kernels that didn't already have it, and I'm assuming this is a similar situation.

ft