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

[WIP] linux: translate kernel config to structured config #12158

Closed
wants to merge 1 commit into from

Conversation

copumpkin
Copy link
Member

Note that this isn't used yet; I'm just seeing what people think. If feedback is positive I'll actually plug it into the real config machinery. I considered doing something fancier by modeling options with the module system but it seemed like a lot of effort for not much gain when in practice most people don't tweak most options, and there's only a handful that people often turn on and off.

This is one approach to #11994.

cc @aszlig whose merging code I borrowed

"KVM_COMPAT?" = whenAtLeast "4.0" "y";
"KVM_DEVICE_ASSIGNMENT?" = whenAtLeast "3.10" "y";
"KVM_GENERIC_DIRTYLOG_READ_PROTECT" = whenAtLeast "4.0" "y";
"KVM_GUEST" = when (!grsecurity) "y";
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the logic here is slightly different because I think the previous one had a bug in it. cc @wkennington for clarification.

https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/common-config.nix#L421-L423 for context.

@edolstra
Copy link
Member

edolstra commented Jan 5, 2016

IIRC, manual-config.nix already has some support for passing a kernel config as an attribute set. At least I see lines like

    config = { CONFIG_MODULES = "y"; CONFIG_FW_LOADER = "m"; };

We should probably unify manual-config.nix and generic.nix but that's probably a separate issue.

"RCU_TORTURE_TEST" = "n";
"SCHEDSTATS" = "n";
"DETECT_HUNG_TASK" = "y";
"CRASH_DUMP?" = "n";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Putting ? in the option names is probably a bad idea because it would complicate merging values. E.g. one module might set CRASH_DUMP? and another CRASH_DUMP. It might be better to move the ? to the right-hand side, e.g.

CRASH_DUMP = "?n";

or in a structured way

CRASH_DUMP = ifSupported "n";

@copumpkin
Copy link
Member Author

@edolstra yeah, I was on the fence about that. It would also allow me to unquote all the attribute names. I'll do that, thanks.

Speaking of merging values, I should probably also warn/barf if there are multiple values for a given key. That starts looking more like the module system again 😄

Note that this isn't used yet. If feedback is positive I'll actually plug
it into the real config machinery.
@copumpkin
Copy link
Member Author

I pushed another version if anyone wants to take a look. I'd rather not make it fancy with the module system at this point, since I don't expect people to be tweaking it all that much, but I can start that process if y'all think it's worthwhile.

My main unknown about the module system is how to mark certain options as irrelevant for certain versions.

@copumpkin
Copy link
Member Author

N.B: this is WIP because if people like the basic idea, I'll actually integrate it with other parts of the kernel config and then expand this PR to include those changes too.

copumpkin referenced this pull request Jan 7, 2016
This helps in some weird screens that otherwise show the console 90° turned.
@aszlig
Copy link
Member

aszlig commented Jan 21, 2016

@copumpkin: 👍 I like the basic idea and also the structured approach, which I had in mind as well. More specifically for my own machines the idea was to have a basic kernel config and then use other NixOS options/modules to extend it using requiredKernelConfig, so it would be cool to tie it in there as well :-)

@rasendubi
Copy link
Member

(triage) @copumpkin status?

@spacekitteh
Copy link
Contributor

I like it! Currently trying to figure out how to stop building all these useless kernel modules I don't need has been a nightmare due to the rather hacky nature of the current system. Yours is much better!

@spacekitteh
Copy link
Contributor

@copumpkin can you merge this?

@copumpkin
Copy link
Member Author

It's going to need updating to account for everything that's changed since I submitted this. I don't have much time right now but might be able to fit it in next week. Would definitely welcome someone else picking it up and pushing it over the line thought :)

On Aug 18, 2016, at 01:00, Sophie Taylor notifications@github.com wrote:

@copumpkin can you merge this?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@spacekitteh
Copy link
Contributor

@joachifm this might be helpful for #17949

@copumpkin copumpkin mentioned this pull request Oct 3, 2016
7 tasks
@cstrahan cstrahan self-assigned this Oct 4, 2016
@spacekitteh
Copy link
Contributor

@grahamc kernel, security, enhancement

@grahamc
Copy link
Member

grahamc commented Nov 5, 2016

@spacekitteh Not sure why security, but I added enhancement / kernel. Can you justify security?

@spacekitteh
Copy link
Contributor

@grahamc many security-related kernel options currently require a custom config file

@grahamc
Copy link
Member

grahamc commented Nov 5, 2016

Is the difference here a different / improved way to configure it, or is it enabling new functionality not available before? Sorry if I'm being dense, I'm in the middle of a move.

@spacekitteh
Copy link
Contributor

Sort of both - it's enabling changing poorly chosen security options within a nix expression

@spacekitteh
Copy link
Contributor

It's a basic principle of security that it should be as easy as possible to make secure; this reduces the burden (and thus likelyhood of mistakes which result in less security)

@spacekitteh
Copy link
Contributor

@copumpkin what's needed for this to be merged?

@NeQuissimus
Copy link
Member

ping :) Is this in a reasonable enough state that it just needs the new kernel configs?

@danbst
Copy link
Contributor

danbst commented Nov 20, 2017

The helper functions (let bindings in the top) deserve a separate file.

@copumpkin
Copy link
Member Author

Realistically, I'm probably not going to finish this anytime soon, but would be happy if someone else picked it up. I just have too much on my plate these days.

@teto
Copy link
Member

teto commented May 29, 2018

While looking at #41103, I am not fond of the "features" system which seems like an unnecessary abstraction as people/systems fiddling with the kernel will be very specific IMO.

Some questions on how to fit this with the current system:

  • how to merge with an extraConfig ? there should be some rules like yes wins over no
  • right now when a setting is set to "m" or "y" it is not overriden by preferBuiltin or autoModules. I would like to have the possibility to ultimately override every ("y" or "m") , i.e., override the "y" as "m" and vice/versa.

I might tackle this since kernel building is still painful, I've started annotating packages I use with some of their required kernel config (bcc/mininet/openvswitch...)

@grahamc
Copy link
Member

grahamc commented May 29, 2018 via email

@teto
Copy link
Member

teto commented Jun 20, 2018

I have updated this PR code and got sthg ready for review #41393.
I would like some feedback as I really would like moving on to packages/modules specifying their kernel dependencies.

@Profpatsch
Copy link
Member

Thanks @teto, closing in favor of #11994

@Profpatsch Profpatsch closed this Jun 23, 2018
@henrytill
Copy link
Member

Thanks @teto, closing in favor of #11994

@Profpatsch: bit of a circular reference here. Did you mean #41393?

@Profpatsch
Copy link
Member

@henrytill yeah

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

Successfully merging this pull request may close these issues.

None yet