Review the kernel builder ergonomics

[samueldr]

The main idea is to finally factor out the things to factor out of the kernel derivations.

Look at the resulting derivations to see what changes were made.

With this, a better understanding of what was done, and what was unneeded was also achieved.

The goal here is to reduce the amount of cargo-culting between the different kernel derivations. By better understanding what was cargo-culted, necessary and unnecessary, I basically documented through the code what was being done.

By reducing the cargo-culting, I should be able to soon add a kernel derivation skeleton to autoport. With some additional detection it should be able to give a pretty solid approximation, while guiding the user appropriately.

What about the patches? The patches are fine still cargo-culted. I'm still thinking about a way to reduce it. Most likely it will look like collection of patches per-SoC. I'm open to other suggestions.

What's the difference between is* and enable* parameters? is are for intrinsic "properties" of the build. enable*, while enable* serves to enable a feature. The distinction becomes a big hazy with things like enableCompilerGcc6Quirk and enableRemovingWerror, but the same applies. The gcc6 quirk or removing Werror is not a property of the build, but a feature needed for the current implementation to work.

---

TODO

• Write some docs about the kernel builder, mainly document the different enable* and is* flags.

---

Verified to boot on every devices except:

• asus-dumo
• google-marlin
• xiaomi-lavender
• xiaomi-tissot

Two of those I do own, but did not test for different reasons. xiaomi-lavender is basically equivalent to the newly introduced sony-pioneer, they're like twins from different mothers. My xiaomi-lavender is currently not usable for testing purposes.

The asus-dumo build is assumed to be fine, as like the pinephone it is a mainline device. It is assumed to be possible to boot since its kpart partition built trivially; testing changes on it is a bit cumbersome.

google-marlin and xiaomi-tissot I don't think are of concern. google-marlin is the same SoC as oneplus-oneplus3, they were similar at first, and are now still similar in the same way. xiaomi-tissot, while sharing its SoC with motorola-addison, cannot really be compared as one is seemingly QCDT-based while the other is not. Though the changes look just fine to me, I'm not concerned.

Though, testing for those devices would be well-received.

---

This PR affects the currently opened ports PRs. As with every time I break the internal definitions, I'm glad to help contributors figuring out what to fix.

• [WIP] device: add lg-hammerhead #24
• [WIP] device: add zte-axon7 #27
• [WIP] device: add google-taimen #38
• [WiP] Google blueline #44
• [WIP] Add oneplus-cheeseburgerdumplings #79
• [WIP] oneplus-bacon: add kernel #89
• lg-hammerhead: init #144
• Port to Motorola G5 Plus (potter) [second attempt] #159
• google-blueline: init #191

---

cc @lheckemann xiaomi-tissot original contributor
cc @danielfullmer google-marlin original contributor

I don't require testing to go forward, but it would be appreciated. (Obviously taking a look at the change and reviewing would be appreciated too.)

[lheckemann]

Works on tissot 👍

[danielfullmer]

Works on google-marlin