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

Add kernel configuration to the system evaluations #410

Merged
merged 29 commits into from Aug 31, 2021

Conversation

samueldr
Copy link
Member

@samueldr samueldr commented Aug 30, 2021

This provides strong guarantees that kernel builds are going to work as expected.

Currently, kernel configurations are quite ad-hoc and hapazard. Some include required kernel config to work correctly, some don't at all.

With these changes, required configuration is validated as part of the kernel builder. Additionally, these required configurations are implicitly added on top of kernel normalization. Meaning that ports should become a bit easier to do; the minimum required kernel configuration is automatically applied.

This is the independent part one of a two part plan, to allow relying on defconfig rather than on fully normalized kernel configurations. Using a defconfig should allow even easier ports in the future, relying on the minimum required amount of information, and relying on defaults for unconfigured options.


Note: This could be a breaking change, mainly at the build level. It might happen that some vendor kernels are messed-up enough that they won't build with the new configuration. I have a strong expectation that if it builds it will still run.

I still need to test on a variety of devices once the numerous builds are done.

TODO

  • Test asus-flo
  • Test asus-x018d
  • test asus-z00t (if USB port cooperates)
  • test amazon-austin
  • Test a few other devices (though none had issues building)

While currently this is not plugged into anything, the intent is to
provide the structured configuration from the modules system.

Different modules will be able to provide kernel configuration options
that are required (or suggested), and the validation will fail the build
if the options are not provided.

A further update will add those options for normalization, allowing the
update to be automatic.

This, finally, is the first move towards providing an alternative route
for kernel configuration; "defconfig + structured config", where a
platform-provided defconfig can be used as a base, and the structured
config "finishes" configuration. Hopefully this should allow using the
defconfig files from the vendor repositories directly, obviating the
need to *somehow* provide a full configuration file.

Note that the full configuration file scheme is expected to stay.

Huh, where's that `eval-config` coming from? ██████████████████
█████ ████████████████ ██████████. Coming soon!
This is not really meant to provide a user-accessible way to configure
the kernel... But it also works that way I guess!

For now it is *meant* to provide *required options*, so that validation
(and soon normalization) always includes required options.
This allows normalization to *automatically* include the required
configuration options as provided by the modules eval.

No more missing options!

Easier porting!
@samueldr samueldr added the 4. type: enhancement New feature or request label Aug 30, 2021
@samueldr
Copy link
Member Author

samueldr commented Aug 30, 2021

List of newly failing builds:

  • asus-x018d
  • asus-z00t
  • asus-flo
  • amazon-austin

What even is ASUS doing?

In reality, it's not as bad as it sounds. Heh. Different issues. asus-x018d is from the mediatek BSP. asus-z00t I think is from a "bad" backport that already caused other issues. Not sure for asus-flo. amazon-austin looks like an issue I've seen in another port where enabling cgroups (IIRC) makes kuid_t different, and code isn't written with that in mind.

So really, total luck that caused so much failure on ASUS devices.

I will not be fixing the asus-flo build; the kernel is too old to actually run the system correctly (3.4). Hopefully mainline efforts (upstream) help make #272 a reality. I tried anyway, but it doesn't seem to boot. I have not verified whether it was supposed to be booting before.

Otherwise the build is broken. Anyway it's *optional* for systemd.
As for now the vendor kernel won't build. It will require extensive
changes to fix the build, **but it is possible**.

Though the fact that it's ARMv7 means I have much less interest in
actually fixing this.

For the time being, it works *enough* that it's a non-issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4. type: enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant