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>
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>
The function ‘mkDerivation’ now checks whether the current platform
type is included in a package's meta.platform field. If not, it
throws an exception:
$ nix-build -A linux --argstr system x86_64-darwin
error: user-thrown exception: the package ‘linux-3.10.15’ is not supported on ‘x86_64-darwin’
These packages also no longer show up in ‘nix-env -qa’ output. This
means, for instance, that the number of packages shown on
x86_64-freebsd has dropped from 9268 to 4764.
Since meta.platforms was also used to prevent Hydra from building some
packages, there now is a new attribute meta.hydraPlatforms listing the
platforms on which Hydra should build the package (which defaults to
meta.platforms).
Having N different copies of the NixOS kernel configuration is bad
because these copies tend to diverge. For instance, our 3.10 config
lacked some modules that were enabled in older configs, probably
because the 3.10 config had been copied off an earlier version of some
older kernel config.
So now there is a single kernel config in common-config.nix. It has a
few conditionals to deal with new/removed kernel options, but
otherwise it's pretty straightforward.
Also, a lot of cut&paste boilerplate between the kernel Nix
expressions is gone (such as preConfigure).
This is for consistency with terminology in stdenv (and the terms
"hostDrv" and "buildDrv" are not very intuitive, even if they're
consistent with GNU terminology).
what the new nix thinks the fuloong is.
Anyone having the old nix should use a nixpkgs previous to this change to build
the new nix. And then, with the new nix, he can use any newer nixpkgs revision.
svn path=/nixpkgs/trunk/; revision=31751
The "unset MODULE_DIR" trick was enough to get Linux 3.x kernels compiling, but it was definitely the Wrong Thing
We NEED MODULE_DIR set so that depmod can store the right dependencies during the build. The REAL problem with the
3.x kernels was two-fold: Our module-init-tools was so old that the kernel build needed to introduce a hack when
calling depmod (involving creating a symlink prepending 99.98 to the version number), and the depmod wrapper was
moved out of the Makefile into scripts/depmod.sh, so our substituteInPlace to get rid of '-b $(INSTALL_MOD_PATH)' in
the Makefile was a noop and INSTALL_MOD_PATH was still being passed to depmod. This is now fixed and modprobe can
successfully find dependencies using the modules.dep created during install
svn path=/nixpkgs/trunk/; revision=29559
With the new kernel versioning scheme, the first release in a series only has a version number and
a major revision number (e.g. linux 3.0, linux 3.1-rc1, etc.). Unfortunately, the module
directory for these kernels still has a minor revision number (e.g. lib/modules/3.0.0, lib/modules/3.0.1-rc1, etc.).
This causes problems for packages such as broadcom_sta that need to know the module directory, so
this attribute will allow setting the module directory version number separate from the
kernel version number when necessary.
svn path=/nixpkgs/trunk/; revision=28405
Moved the hardcoded postBuild hook from the builder to generic.nix:
Some old kernel (such as 2.6.15) did not yet support the unifdef target.
As a result, compiling them with the current Linux builder leads to a
failure.
Fixed by moving this hook as argument of the top-level function of
generic.nix. This allows some kernel nix codes to overrides its default
value.
svn path=/nixpkgs/trunk/; revision=27708
In fact only 2.6.34 boots fine, while 2.6.35 needs a fetchsvn new revision,
waiting for an upstream patch.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23039
on the native and cross platforms.
I thought I already did that today in a previous commit, but I did all wrong.
svn path=/nixpkgs/trunk/; revision=20280
I fixed conflicts regarding the renaming 'kernel' -> 'linux' in all-packages.
Also a small conflict in all-packages about making openssl overridable.
And I some linux 2.6.31-zen kernel files also marked in conflict.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19438
most of the kernel expressions for the sheevaplug).
I still have not added anything in the kernels about cross compilation.
I moved the platform definitions out of all-packages.
I have not written good platform definitions for the sheevaplug - only for the
PC.
Only the linux-2.6.32 expression uses the platforms kernelConfig.
The linux-2.6.31 was broken, and I left it broken.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19046
sheevaplug kernel, so the kernel does not build in the sheevaplug right now.
I will try to fix that in next commits.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19045
