[Nix-dev] [Nix-commits] [NixOS/nixpkgs] bf7467: Add first attempt at linux/kernel/manual-config.

[Shea Levy]

Hi,

On Jul 29, 2012, at 10:24 AM, Eelco Dolstra <eelco.dolstra at logicblox.com> wrote:

> Hi,
> 
> On 29/07/12 05:09, Shea Levy wrote:
> 
>>  Log Message:
>>  -----------
>>  Add first attempt at linux/kernel/manual-config.
>> 
>> The goal of this function is to make it possible to build a kernel with a user provided .config.
> 
> Could you say a bit more about what this means and what the advantages are?
> 

Basically, it allows you to build a kernel after configuring it with the official kernel config mechanisms (e.g. make menuconfig) rather than using our automated system. By trying to make as many options modular as possible, the standard system is great for general use, but some users (e.g. me) may not want or need all those modules and may prefer to configure their kernels the traditional way.

The feature autodetection is a big plus as well, as hopefully it will enable NixOS to fail early if the kernel doesn't do enough for a given module to work.

>> As a secondary goal, it will extract NixOS-relevant features from the config automatically.
>> As a tertiary goal, the build will aim to be simpler than the current generic kernel builder.sh.
>> 
>> Unfortunately, that simplicity is offset by the complexity of the feature extraction, especially since nix segfaults when trying to split the file into lines (so an import from a derivation is used)
> 
> Unfortunately using an import from a derivation means this shouldn't be in
> Nixpkgs right now.  Won't this cause a build when I do "nix-env -qas"?
> 

No, since the attribute in nixpkgs is a function, not a derivation. The import-from-derivation is only triggered when you call the function with your config and kernel source, and if it's not desired then then you can pass in features yourself as well.

> Also, Nix is not a general-purpose programming language.  It's really not the
> right language for doing things like processing a .config file, especially since
> this will end up slowing down every "nix-env -qas" call.
> 

I know, I only did it originally since I was trying to avoid importing from a derivation, but since I couldn't do that anyway I can put the rest of the processing into the import.

> P.S. a new kernel config system is the sort of feature that would be good to
> keep in a branch until it's been reviewed/discussed a bit.
> 

This was meant to be a supplement, not a replacement, so I thought there'd be little harm in having it in master, but I can revert the merge for now if you like.

> -- 
> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/

~Shea