build.nix accepted `features` as a parameter but discarded it, never
placing it into the derivation's passthru. The NixOS boot.kernelPackages
apply function calls kernel.override() on every evaluation, re-running
build.nix from scratch; any features added via overrideAttrs were
silently lost, causing assertions like hardware.graphics.enable32Bit
(which checks kernel.features.ia32Emulation) to always fail for
linuxManualConfig-based kernels.
Change `features ? null` to `features ? {}` and add it to passthru so
it survives override() call chains.
Currently, you need to override `stdenv.hostPlatform` to request a
compressed kernel on AArch64, and the kernel configuration is split
between the central structured configuration and string snippets in
platform definitions. This has consequently made the latter bitrot
terribly. Since the platform‐specific logic is now very limited after
cleaning up the detritus, we can move it into the kernel derivation
and expose the relevant configuration there for anyone who wants to
customize it further or needs to read it out.
Co-authored-by: zowoq <59103226+zowoq@users.noreply.github.com>
Now that ARMv5 no longer uses `uImage`, there’s no point in keeping
around support for this deprecated format that the rest of the NixOS
infrastructure doesn’t handle. Modern U‐Boot setups should not
be affected in any way by this.
Because it isn't stripped by default, and is outside of the list of paths that we strip automatically.
dev output is expected to have an unstripped vmlinux, so stripping this one should be fine.
This partially reverts commit 845e340ed9.
This re-introduces the `pos` juggling previous done.
The rationale used in the commit was:
> This is long obsolete since the versions are maintained in a JSON
> file now.
That is only accurate for `mainline`. Other in-tree kernels are
maintained in different ways. This led to a loss of information.
Before (cf3f5c4def):
```
nix-repl> linux_latest.meta.position
".../pkgs/os-specific/linux/kernel/mainline.nix:34"
nix-repl> linux_rpi0.meta.position
".../pkgs/os-specific/linux/kernel/linux-rpi.nix:20"
```
After (2fb006b87f):
```
nix-repl> linux_latest.meta.position
".../pkgs/os-specific/linux/kernel/build.nix:558"
nix-repl> linux_rpi0.meta.position
".../pkgs/os-specific/linux/kernel/build.nix:558"
```
This is also observable for out-of-tree kernels:
```
nix-repl> pkgs.linux_jovian.meta.position
".../Jovian-NixOS/pkgs/linux-jovian/default.nix:11"
nix-repl> :r # after updating the Nixpkgs input
nix-repl> pkgs.linux_jovian.meta.position
"/nix/store/xjjq52iwslhz6lbc621a31v0nfdhr5ks-source/pkgs/os-specific/linux/kernel/build.nix:558"
```
This also conveniently works around the root cause of an
`stdenv.mkDerivation`-based `pos` infrec regression when using the
kernel package version in a NixOS configuration to conditionally
apply kernel patches.
In #448835 I renamed `config` to `configHelpers` to save a
`config_ = config;`, however `config` having the `is*` helpers is kinda
public API (as proven by NixOS modules failing to evaluate).
As a result, this commit adds the helpers back to `config` that is
exposed by the kernel derivation.
Apologies, I'm pretty sure I fixed that before locally and it just got
lost during a rebase :(
Since I started touching this subsystem, I found the name confusing
since this is the part where we actually compile the kernel and we have
a ready-to-use configuration.
The stated goal of the commit introducing it[1] is to provide a function
to
> make it possible to build a kernel with a user provided .config.
Considering that this is supposed to be a differentiation from other
build mechanisms and nowadays this is the only way to build kernels in
nixpkgs, I figured that `build.nix` is a better name.
`pkgs.linuxManualConfig` isn't renamed on purpose: Kloenk and I are
planning to do more involved work and it may become necessary to change
parts of the API. So asking users to do a migration now just to add
another one soon isn't worth it.
[1] bf7467cbb1
