Xen is now enabled unconditionally on kernels that support it, so the
xen_dom0 feature doesn't do anything. The isXen attribute will now
produce a deprecation warning and unconditionally return true.
Passing in a custom value for isXen is no longer supported.
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
Don't include an NT_GNU_BUILD_ID (that is randomly generated
at build time).
This improves the kernel reproducibility: when also disabling
the MOUDLE_SIG and SECURITY_LOCKDOWN_LSM options the build
is bit-by-bit reproducible.
utillinux depends on systemd because:
* uuidd supports socket activation
* lslogins can show recent journal entries
* fstrim comes with a service file (and we use this in NixOS)
* logger can write journal entries
(See https://www.openembedded.org/pipermail/openembedded-core/2015-February/102069.html)
systemd doesn't depend on utillinux but on utillinuxMinimal which is a
version of utillinux without these features to avoid cyclic
dependencies.
With this change, the linux kernel (of which i don't fully understand
why it would depend on util-linux in the first place, but this was added in
https://github.com/NixOS/nixpkgs/pull/32137/files without too much
explanation) depends on the minimal version of util-linux too.
This makes it that every time we change build flags in systemd
the linux kernel doesn't have to wastefully rebuild.
Go beyond the obvious setup hooks now, with a bit of sed, with a skipped case:
- cc-wrapper's `dontlink`, because it already is handled.
Also, in nix files escaping was manually added.
EMP
In 5.2 kernel a new mechanism was introduced which embeds the kernel
headers in the kernel image and exposes them in procfs for simplified
use by userland tools.
It was introduced in
43d8ce9d65
and later modified a bit in
f7b101d330
The archive containing the header files had nondeterminism through the
header files metadata - specifically `mtime`, but I also decided to
normalize some other aspects just in case.
In our default setup we currently compile this as a module, so to expose
the headers to test the functionality `kheaders` needs to be loaded.
See https://lkml.org/lkml/2019/10/4/1036 and
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=fixes&id=2cc99c9cdc8fde5e92e34f9655829449cebd3e00
I commented out the documentation part of the patch to make it cleanly apply to
5.2 and 5.3, see remark in the patch itself.
81d4e65891 automatically bumped
linux_testing to 5.2.0-rc1, but the 5.2 merge window included a new
feature adding compressed headers for compiled kernels into
/proc/kheaders.tar.xz
See 43d8ce9d65
This feature requires 'cpio' to now be included in nativeBuildInputs
since it's used to construct that archive.
This wasn't caught by Hydra since we turn off build of linuxPackages,
but ideally we should at least build the kernel in the future
(linux_testing itself.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Some packages don’t work correctly with pie. Here I disable it for:
- busybox
- linux kernel
- kexectools
I also get rid of the Musl conditional for disabling pie in GCC and
Binutils. Some day we might want to enable PIE without Musl and it
will be useful to have the *just* work with our compiler and linkers.
Since commit f620b1b693, the build directory is located inside the
source directory. Thus, the `cp -dpR` copies gigabytes worth of .o files
only to be deleted later on when we trim all non-essential files from
`$dev/lib/modules/${modDirVersion}/source/` thus causing a significant
amount of wasted I/O and peak disk usage.
As `cp` doesn't come with a `--exclude` flag, use rsync. And throw out
the Documentation folder while at it.
Instead of using a string to describe kernel config, use a nix
attribute set, then converted to a string.
- allows to override the config, aka convert 'yes' into 'modules' or
vice-versa
- while for now merging different configs is still crude (last spec wins),
at least there should be only one CONFIG_XYZ value compared to the current string
config where the first defined would be used and others ignored.
[initial idea by copumpkin in 2016, a major rebase to 2018 by teto]
The required argument 'hostPlatform' was missing from linuxPackages_custom's
call to linuxManualConfig.
In order to prevent this in the future, this commit adds
linuxPackages_custom_tinyconfig_kernel so linuxPackages_custom gets tested.
This also adds linuxConfig, to derivate default linux configurations
via make defconfig, make tinyconfig, etc.
Closes#38034.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
- 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.
