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]
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
Avoids the following warning:
File /.../systemd-journald.service:35 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.
Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)
They got removed:
commit 003948c54e5b5034a9bbb4923336f5aba125eae6
Author: Benjamin Gilbert <benjamin.gilbert@coreos.com>
Date: Tue Jan 23 18:06:30 2018 -0800
USB: serial: keyspan: Drop firmware Kconfig options
The USB_SERIAL_KEYSPAN_* firmware options no longer do anything.
No reason to have complex version-dependent conditionals when the
question mark already handles this just as well.
Also add RUNTIME_TESTING_MENU setting which nicely disables all of this
on >= 4.16.
- 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
With this disabled, cameras would not get a `/dev/mediaX` entry matching
the `/dev/videoX` which broke any application (e.g: `uvcdynctrl -l`,
`media-ctl -p`) depending on this interface.
Since we don't have a split debug info output yet, don't waste time
writing several gigabytes of debug info that's all going to be stripped
out at the end.
This change only affects Aarch64 (where some joker has enabled it in the
architecture defconfig) and is a no-op on the others.
There is no maintainer for this package, probably not many users.
It requires effort to fix all third-party modules for this old kernel
versions. It might contain unpatched security holes.
For Pixel chromebooks, we have the samus-kernel.
Apart from that https://github.com/GalliumOS/linux might be a good choice.
