With the current patching situation around enabling Linux to build
with whatever rustc/bindgen version we have in nixpkgs, it feels like
supporting a Rust-by-default build at this time is not fully
justified.
Co-authored-by: Julian Stecklina <julian.stecklina@cyberus-technology.de>
Since 41f788b121 ("linuxManualConfig: use the default make target"),
we don't know ahead of time whether the kernel build will attempt to
produce a uImage in addition to whatever we're expecting it to build.
ubootTools is not a big dependency, so let's just always include it.
I read this comment, checked out 4.19, saw that it didn't have any
instances of /bin/pwd, and rejoiced, assuming that the removal must
have been backported to the affected kernels. But actually, /bin/pwd
was just removed earlier, in 4.15, so kernels older than that are
still affected.
Fix the version number in the comment so I don't go through exactly
the same process again a few months from now next time I'm working on
this file.
Since https://github.com/NixOS/nixpkgs/pull/221707 the `isModular`
and `buildDTBs` parameters no longer function properly -- they now
control only whether or not these elements are copied to the
outpath; they are build unconditionally in any case.
This commit reverts the part of #221707 which caused this behavior
change.
Since https://github.com/NixOS/nixpkgs/pull/221707 we must ensure
that the image resulting from a kernel build is stripped. If we do
not do this, there will be circular dependencies among its outpaths.
This commit fixes the breakage on mips.
Closes#224694
Since 41f788b121 ("linuxManualConfig: use the default make target"),
we don't know ahead of time whether the kernel build will attempt to
produce a uImage in addition to whatever we're expecting it to build.
ubootTools is not a big dependency, so let's just always include it.
With this change, we can do a reasonable default build of Linux for
configurations that do not have a corresponding platforms.nix entry,
and where the user has not explicitly specified the linux-kernel
values. This allows us to do best effort builds for obscure
architectures (I tested a build for s390x).
The platformName binding has not been used since
70cb7050f5 ("Trying to make the linux kernels also cross-build."),
so I removed it.
Fixes reproducibility issues with x86/amd64 VDSO ELFs Build-IDs.
The kernel build system tries pretty hard to not leak build file paths
in its output. However, the embedded VDSO ELF files are built using
slightly different build options that do not include the path mapping
options that protect the rest of the kernel against this issue.
This should be fixed upstream eventually, but a lot of this logic is
duplicated across architecture, so I don't expect it will be a trivial
fix. Instead, make our derivation use a fixed build root directory so
this does not impact the build reproducibility.
Fixes#227800.
I read this comment, checked out 4.19, saw that it didn't have any
instances of /bin/pwd, and rejoiced, assuming that the removal must
have been backported to the affected kernels. But actually, /bin/pwd
was just removed earlier, in 4.15, so kernels older than that are
still affected.
Fix the version number in the comment so I don't go through exactly
the same process again a few months from now next time I'm working on
this file.
This is an attempt to make linuxManualConfig look a lot more like a
normal package. Previously, about half the attributes passed to
mkDerivation come from calling a "drvAttrs" function, which just
served to alias some variables through function parameters. There
wasn't really a system for which attributes came from drvAttrs, and
which did not.
I've also made a few other minor changes, like re-ordering attributes
to be more idiomatic, and using variables that were moved out of
drvAttrs in the definitions of attributes that weren't in drvAttrs
before. I've limited my changes here to what I can confidently do
without causing any rebuilds.
This seems to be needed for out-of-tree module builds since d57568fcad.
We do not yet understand why, but this will unblock the channels while
we figure it out.
Fixes: d57568fcad ("linuxManualConfig: install GDB scripts")
These are required to debug kernel modules. Since we're now able to
do that, there's another reason besides BTF to enable DEBUG_INFO, so
I've done that for pre-BTF kernel modules as well here.
For GDB to get configured correctly, vmlinux-gdb.py has to be two
directories up from scripts/gdb, and vmlinux has to be next to
vmlinux-gdb.py. The least invasive way to satisfy these constraints
is to make vmlinux a symlink, which GDB will resolve before looking
for vmlinux-gdb.py.
Tested both ways of getting the scripts into GDB that I know of:
gdb /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/vmlinux \
-iex 'add-auto-load-safe-path /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/lib/modules/6.1.19/build/vmlinux-gdb.py' \
-ex 'lx-version' \
-ex 'q'
gdb /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/vmlinux \
-ex 'source /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/lib/modules/6.1.19/build/vmlinux-gdb.py' \
-ex 'lx-version' \
-ex 'q'
Also tested that the strip changes don't result in meaningful output
size changes (there's some small variation due to BTF data not always
coming out the same size, which is unrelated), and built every kernel
I can on x86_64 to make sure I'm not relying on build system behaviour
specific to newer kernels.
We've basically been reimplementing this — by default it contains
vmlinux, dtbs (on applicable architectures), modules, and architecture
specific stuff like $(KBUILD_IMAGE) and a couple of other
miscellaneous files.
linux is unusual in that we include its sources in an output. There's
no point unpacking into /build when we're going to copy the sources
into $dev later. Let's unpack directly into the final destination of
the code, and save copying a whole kernel source tree (often across
filesystems!).
This also means that Kbuild knows the location of the sources, which
will allow us to install the GDB scripts — some scripts are generated,
and some are not, so the generated ones end up in the build directory,
accompanied by symlinks to the non-generated ones in the source
directory.
Assuming the dead link refers to
https://lore.kernel.org/linux-kbuild/1443741332.2730.75.camel@decadent.org.uk/
at this point it's fairly safe to say it's not getting in, as it
hasn't been resubmitted since 2015, and nowadays the kernel
documentation just suggests setting KBUILD_BUILD_TIMESTAMP like we do
here.
Linux has a few PowerPC-specific symbols which are marked as GPL exports; these
symbols wound up being exposed in Linux 5.12 and are needed by OpenZFS. The
symbol licensing was fixed in mainline 5.19; this commit backports the fix to
all previous affected kernels.
This commit is required in order to build the NixOS ISO for PowerPC64.
Reverts 7c7c83e233 which was
only needed for the minimal-kernel.nix test module and clutters the call site.
stdenv can still be overridden with `linuxManualConfig.override { stdenv = ...; }`.
