The kernel checks the version of pahole at configuration time to know
if it supports features like split BTFs. If pahole doesn't exist,
all of that gets disabled in the config file, so the kernel ends up
built without split BTFs, despite having a working pahole for the actual
build.
With this change it's ensured that `builtins.unsafeGetAttrPos` actually
points to `<nixpkgs/pkgs/os-specific/linux/kernel/linux-x.y.nix>` when
retrieving the position of `src` or `version` of
`linuxPackages.kernel`.
This is relevant to make sure that ofborg pinging maintainers on kernel updates
actually works[1]. While the underlying issue should be fixed in ofborg
or Nix itself, this is IMHO a pragmatic change to ensure that all kernel
maintainers are automatically notified on updates.
[1] https://github.com/NixOS/nixpkgs/pull/143113#issuecomment-953319957
Unfortunately, there seems to be no way of referencing an overridable version of
the package you're in, so it had to be stubed to work at all.
This isn't important for our current, very basic kernel nixosTests but might
become important when we add more sophisticated ones.
We should be using the _same_ buildPackages when we generate the
configuration (which happens in buildLinux) as when we actually build
the kernel (which happens in linuxManualConfig).
This change enforces that when we callPackage `manual-config.nix` we
pass on whatever `buildPackages` that `buildLinux` itself was called
with.
This is just for practicity, as it allows users of buildLinux to pass
along extra flags they need in the kernel's make invocation. This makes,
for example, supporting LLVM _much_ easier, and could enable us in the
future to provide clang-built kernels.
This enforces that the configuration generated will obey any/all flags
set in the platform/stdenv configuration. This is crucial, for example,
if you'd like to build a kernel using clang.
Without this patch, anything you set in
`stdenv.hostPlatform.linux-kernel.makeFlags` is wholly ignored during
config generation, causing (for example) any changes in the desired
toolchain (e.g. `LLVM`, `LLVM_IAS`) to not be reflected in the generated
config, and for the subsequent build to fail.
Nixpkgs hasn't supported grsecurity kernels since 2017, so unless
anybody is manually enabling the grsecurity feature to make these
small kernel tweaks this is dead code.
This means we don't actually support any "features" in the kernel
common-config any more, but I've left the argument there because it's
conceivable we could have some again in future.
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.
This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
This should make the composability of kernel configurations more straigthforward.
- now distinguish freeform options from tristate ones
- will look for a structured config in kernelPatches too
one can now access the structuredConfig from a kernel via linux_test.configfile.structuredConfig
in order to reinject it into another kernel, no need to rewrite the config from scratch
The following merge strategies are used in case of conflict:
-- freeform items must be equal or they conflict (mergeEqualOption)
-- for tristate (y/m/n) entries, I use the mergeAnswer strategy which takes the best available value, "best" being defined by the user (by default "y" > "m" > "n", e.g. if one entry is both marked "y" and "n", "y" wins)
-- if one item is both marked optional/mandatory, mandatory wins (mergeFalseByDefault)
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]
common-config.nix has:
${kernelPlatform.kernelExtraConfig or ""}
and indeed kernelExtraConfig is in hostPlatform.platform, and not in
hostPlatform. (Ugh.).
- 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
