When doing the 5.0 rebase, I mistakenly thought a conflict meant
a patch had been merged. Turns out, it was an actual (minor) conflict.
Bring back the rebased patch which can actually be dropped with 5.1.
Packaging this is a bit more complicated than expected and
lets to errors when building external modules. Turn this off
for now until we find a better solution.
There's a one or more patches missing. The fix came as part of a 10
patch series, with the first two marked for stable. However, at least
one later patch in series appears to be required.
The shipped .config files all have CONFIG_TICK_CPU_ACCOUNTING and
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE set. The x86_64 .config files
additionaly have CONFIG_VIRT_CPU_ACCOUNTING_GEN set.
This is wrong because each .config should have just one of these three
set. As a result the build generates
[...]⚠️ override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state
24 times and
[...]⚠️ override: VIRT_CPU_ACCOUNTING_GEN changes choice state
4 times. So let's make sure the shipped .config files only have one of
these three Kconfig macros set (ie, the one that's relevant for that
.config target).
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
The shipped .config files all have CONFIG_FLATMEM_MANUAL and
CONFIG_SPARSEMEM_MANUAL set.
This is wrong because each .config should have just one of these two set
set. (There's also CONFIG_DISCONTIGMEM_MANUAL but Fedora doesn't use
that.) As a result the build generates
[...]⚠️ override: SPARSEMEM_MANUAL changes choice state
24 times.
If the configuration generation system drops CONFIG_FLATMEM_MANUAL the
warnings go away. And that doesn't change the final .config files that
the kernel's build system actually uses.
(Two details that very few people will care about:
1. x86/i686 still needs to unset CONFIG_FLATMEM_MANUAL to keep
process_configs.sh from killing the build;
2. the kernel build of armv7hl will silently drop
CONFIG_SPARSEMEM_MANUAL. Because of that I didn't bother with an
explicit override for arm/armv7.)
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
