- defined buildLinux as generic.nix instead of manual-config.nix. This
makes kernel derivations a tad more similar to your typical derivations.
- moved $buildRoot to within the source folder, this way it doesn't have to be created before the unpackPhase
and make it easier to work on kernel source without running the unpackPhase
[...]
make modules -C /nix/store/h1vzl6bq4wif3m8dd1bw2p3fv4shjg3n-linux-4.14.9-dev/lib/modules/4.14.9/build EXTRA_CFLAGS=-Werror-implicit-function-declaration M=/tmp/nix-build-spl-kernel-2017-11-16-4.14.9.drv-0/source/build
/nix/store/h1vzl6bq4wif3m8dd1bw2p3fv4shjg3n-linux-4.14.9-dev/lib/modules/4.14.9/source/Makefile:939: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.
This patch introduces kernel.moduleBuildDependencies to avoid the logic "stdenv.lib.optional (stdenv.lib.versionAtLeast kernel.version "4.14") libelf" in multiple places.
[dezgeg did some minor tweaks on top]
For a while now, the only thing the 'uboot' attribute does is to tell
whether to add ubootTools to kernel/initrd builds. That can be
determined with platform.kernelTarget == "uImage" just as well.
Because if you get it wrong, you get a very confusing error message at
the end of the kernel build, which is quite painful as the build can
take a long time.
[dezgeg: note that we are currently using just 'Image' instead of
'Image.gz' as U-Boot doesn't support the latter yet. We might switch
once it does since the kernel images are quite big]
It takes some extra 13MB (and in dev, not out), but allows perf to show kernel
symbols when profiling. I think it is worth it.
In my NixOS, I refer to it in the system derivation, for easy telling to perf
through /run/booted-system/vmlinux:
system.extraSystemBuilderCmds = ''
ln -s ${config.boot.kernelPackages.kernel.dev}/vmlinux $out/vmlinux
'';
The following parameters are now available:
* hardeningDisable
To disable specific hardening flags
* hardeningEnable
To enable specific hardening flags
Only the cc-wrapper supports this right now, but these may be reused by
other wrappers, builders or setup hooks.
cc-wrapper supports the following flags:
* fortify
* stackprotector
* pie (disabled by default)
* pic
* strictoverflow
* format
* relro
* bindnow
Since commit 48f51f1185 we let the kernel build system compress the
modules, which makes the original strip expression not work. Let the
kernel build system strip them as well so they get stripped.
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
The current default multiple-output propagation rules don't seem to work
too well if the dev output isn't the first one; without this we get an
unnecessary runtime reference to the kernel headers.
I added platform.kernelMakeFlags. This allows setting the required
parameter to make the required kernel uImage for the sheevaplug,
since it became a platform with devicetree (3.10).
I have tried it with linux 3.18 and it built fine.
When building kernels outputting a zImage, the zImage wasn't correctly copied in
to the installation. This broke the build process entirely, at least on my ARM
machine.
Testing showed the linux build is sensitive to /usr/include/ncursesw
unless chrooted (on non-nixos).
On a single chrooted nixos machine, -A linux is binary reproducible.
CC #2281 & @alexanderkjeldaas.
Based on access analysis with strace, I determined an essentially
minimal required set of files from the kernel source that was needed to
build all current kernel packages on 3.10, which ultimately resulted in
keeping 30M of source. Generalizing from that minimal set, which
required ad-hoc specifications of which headers outside of include/ and
arch/*/include and which files in the scripts/ directory should be kept,
to a policy of keeping all non-arch-specific headers that aren't part of
the drivers/ directory and the entire scripts/ directory added an
additional 17M, but there was nothing in the analysis that indicated
that that ad-hoc specification was at all complete so I think the extra
hit is worth the likely greater compatibility.
For reference, we now keep:
* All headers that are NOT in arch/${notTargetArch}/include or drivers/
* The scripts/ directory
* Makefile
* arch/${targetArch}/Makefile
IMO the most likely cause of future problems are the headers in
drivers/, but hopefully they won't actually be needed as they add 50M
Ideally kernel packages would only use include and
arch/${targetArch}/include, but alas this is observably not the case.
master:
* $out
* size: 234M
* references-closure: linux-headers, glibc, attr, acl, zlib, gcc,
coreutils, perl, bash
merge-kernel-builds:
* $out
* size: 152M
* references-closure: none
* $dev
* size: 57M
* references-closure: linux-headers, glibc, zlib, gcc
So even with the non-minimal set we still beat out master. Keeping the
drivers headers would make us only slightly bigger.
Signed-off-by: Shea Levy <shea@shealevy.com>
In most cases, this just meant changing kernelDev (now removed from
linuxPackagesFor) to kernel.dev. Some packages needed more work (though
whether that was because of my changes or because they were already
broken, I'm not sure). Specifics:
* psmouse-alps builds on 3.4 but not 3.10, as noted in the comments that
were already there
* blcr builds on 3.4 but not 3.10, as noted in comments that were
already there
* open-iscsi, ati-drivers, wis-go7007, and openafsClient don't build on
3.4 or 3.10 on this branch or on master, so they're marked broken
* A version-specific kernelHeaders package was added
The following packages were removed:
* atheros/madwifi is superceded by official ath*k modules
* aufs is no longer used by any of our kernels
* broadcom-sta v6 (which was already packaged) replaces broadcom-sta
* exmap has not been updated since 2011 and doesn't build
* iscis-target has not been updated since 2010 and doesn't build
* iwlwifi is part of mainline now and doesn't build
* nivida-x11-legacy-96 hasn't been updated since 2008 and doesn't build
Everything not specifically mentioned above builds successfully on 3.10.
I haven't yet tested on 3.4, but will before opening a pull request.
Signed-off-by: Shea Levy <shea@shealevy.com>
This makes the disk usage footprint of building the kernel smaller in 3
ways:
1) There is no separate kernel source derivation
2) Rather than using the entire build tree, only the output of make
modules_prepare is kept in the $dev output (plus the module symbol
versioning file generated during the build)
3) Only the subset of the source tree known to be needed for external
builds is kept in $dev
Note that while 2) is supported by official kernel documentation, I
couldn't find any source describing what we need to keep for 3). I've
started with the bare minimum (the main Makefile is called by the
Makefile generated by make modules_prepare) and we can/should add more
as needed for kernelPackages.
Signed-off-by: Shea Levy <shea@shealevy.com>
This has three major benefits:
1. We no longer have two kernel build processes to maintain
2. The build process is (IMO) cleaner and cleaves more closely to
upstream. In partuclar, we use make install to install the kernel and
development source/build trees, eliminating the guesswork about which
files to copy.
3. The derivation has multiple outputs: the kernel and modules are in
the default `out' output, while the build and source trees are in a
`dev' output. This makes it possible for the full source and build tree
to be kept (which is expected by out-of-tree modules) without bloating
the closure of the system derivation.
In addition, if a solution for how to handle queries in the presence of
imports from derivations ever makes it into nix, a framework for
querying the full configuration of the kernel in nix expressions is
already in place.
Signed-off-by: Shea Levy <shea@shealevy.com>
In the most general case, the cross and native kernel may differ in
patches and configuration file as well as architecture, kernel target,
etc. It's probably overkill to support that case, but since it was
doable without much duplication and it will make integrating with the
existing cross-compilation support in the generic kernel I decided to
implement it anyway.
Signed-off-by: Shea Levy <shea@shealevy.com>
nix's version parsing treats the previous name as a package named
`linux' with version `${version}-source', when we really want a package
named `linux-source' with version `${version}'
Signed-off-by: Shea Levy <shea@shealevy.com>
This only affects the `oldaskconfig' make target, so it shouldn't really
affect current manual-config users, but it does make it more
straightforward to implement the generic kernel build on top of
manual-config.
Signed-off-by: Shea Levy <shea@shealevy.com>
If the config attrset is manually specified, we still want isYes,
isModule, etc. to work. But we let the passed in config attrset take
precedence, if for some reason the caller wants to provide their own
implementation of one or more of these functions.
Signed-off-by: Shea Levy <shea@shealevy.com>
With this, I was able to successfully compile a defconfig kernel for the
sheevaplug, though I didn't actually try to run it (not having a
sheevaplug myself).
For native compiles, the most significant difference is that the
platform's kernel target is built directly rather than hoping the
default make target will pull it in.
Also some stylistic improvements along the way.
Signed-off-by: Shea Levy <shea@shealevy.com>
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.
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@70730bca13
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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>
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.
