Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review the kernel builder ergonomics #212

merged 32 commits into from Oct 3, 2020


Copy link

@samueldr samueldr commented Oct 2, 2020

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.


  • 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.

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.)

Copy link

Works on tissot 👍

@samueldr samueldr force-pushed the feature/refreshed-kernel-builder branch from 003fb05 to 9210f71 Compare October 2, 2020 23:49
@samueldr samueldr force-pushed the feature/refreshed-kernel-builder branch from d80ba7b to 36a99a3 Compare October 3, 2020 00:43
@samueldr samueldr merged commit 481c6a9 into NixOS:master Oct 3, 2020
@samueldr samueldr deleted the feature/refreshed-kernel-builder branch October 3, 2020 01:52
Copy link

Works on google-marlin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

Successfully merging this pull request may close these issues.

None yet

3 participants