| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
This makes it possible to still build out-of-tree modules without making a system using this kernel depend on the full source and build tree at runtime.
Note that references to the source tree are removed from kernel modules after build.
Ideally, this would be accomplished by modifying the Makefile that puts the reference there in the first place, but I haven't tracked that down yet.
|
|
It makes more semantic sense there than in unpackPhase, as that symlink is _how_ we configure the kernel
|
|
There's no need to set the postFixup env var at all if we're not modular.
|
|
Conflicts (simple):
pkgs/applications/networking/browsers/chromium/default.nix
pkgs/development/libraries/libsoup/default.nix
pkgs/os-specific/linux/kernel/manual-config.nix
pkgs/os-specific/linux/qemu-kvm/default.nix
|
|
As timeconst.pl was replaced by a bc script in the merge window for kernel 3.9,
we also need bc during build time, for more information about the reasons,
please have a look at the following commit:
torvalds/linux@70730bca1331fc50c3caacaea00439de1325bd6e
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
Conflicts:
pkgs/development/compilers/gcc/4.7/default.nix
Trivial solution.
|
|
Likewise for propagatedBuildNativeInputs, etc. "buildNativeInputs"
sounds like an imperative rather than a noun phrase.
|
|
The previos version did a for loop over the output of set, which spits out _all_
defined variables and their contents. This not only is dangerous if there is a
variable starting with CONFIG_ but also can't handle whitespace, as the IFS is
set to any (horizontal _and_ vertical) whitespace by default.
So, imagine (actually don't imagine, something like this is the case in a lot of
kernel configuration files) you have the following variable:
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi ..."
A loop with for and the default IFS would result in the following variable
pieces:
0: CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi
1: -fcall-saved-rsi
2: ..."
This obviously leads to the problem that this config variable is being cut off
at the first whitespace.
Another downside of this approach is that set not only returns variables but
functions as well. This could lead to quite a lot of unexpected behaviour and
confusion.
So the new approach doesn't source the kernel configuration anymore but uses
`read` to parse the file line-by line, setting IFS to '=', thus splitting all
configuration lines into key/value pairs.
Using parameter expansion, we ensure that we only read lines starting with
"CONFIG_". This particularily has the advantage of not being bash-specific,
should we choose to change to a different default shell someday.
Now, after we got a correct "CONFIG_" line, we're using a temporary variable to
split off the first quote from the result. Particularily the reason behind this
is shell compatibility again, as ${${foo#"}%"} only works in Bash, Zsh and
whatnot but not in plain SH.
And within the next line we obviously insert the no_firstquote variable without
it's last quote removed.
But, what about escaping?
First of all, if we'd just eval the $val variable, we would correctly unescape
the value, but this has the downside that variables within the content would be
expanded, for example look at this:
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
Well, obviously this is a bad example at the Nix sense, but just to show that
variables within kernel configuration entries aren't impossible.
And second, which would have been a show stopper if \" would be within $val: It
simply would end up being an invalid Nix expression, because \" would end up as
a ploin " within a double quoted string.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
rather than using a symlink
|
|
Since we keep the source in the kernel build anyway, no space is wasted by having a separate store path for the unpacked source. The upside is that the same source can be used to build the kernel multiple times, or generate configurations for later kernel builds, without going through the (fairly long) unpack and patch process multiple times.
|
|
|
|
|
|
CONFIG_MODULES=y but no modules are actually installed
|
|
list
|
|
stdenv.platform.kernelTarget
|
|
prior to make *_install.
It is probably a kernel build system bug that this is necessary, but it's not really a big deal either.
|
|
|
|
FIRMWARE_IN_KERNEL is left unspecified
|
|
firmware is installed.
Instead of manually adding which 'features' a kernel has based on its config here, just generate a nixexpr representation of the whole config and let places that need it (e.g. NixOS modules) decide how to map config options to features.
Note that if your kernel requires firmware whose hex file sits directly in ${src}/firmware rather than in a subdirectory thereof, you may need this patch for now: https://lkml.org/lkml/2012/7/31/724
|
|
|
|
|
|
imported-from derivation
|
|
|
|
the source directory after the source directory is moved
|
|
|
|
|
|
|
|
|
|
|
|
|
|
and source trees into $out
|
|
symlinking it
|
|
know how to escape properly
|
|
|
|
|
|
with LILO, so install the kernel manually
|
|
|
|
|
|
The goal of this function is to make it possible to build a kernel with a user provided .config.
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)
|
