A couple of CONFIG file names were misnamed during their creation.
Fix them up.
configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible -> configs/fedora/generic/CONFIG_DEBUG_VM_RB
and
configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug -> configs/fedora/generic/CONFIG_DPM_WATCHDOG
The previous patch moved the configs/base-{generic,debug} to configs/fedora.
Now we update the scripts to reflect that change. Changing the scripts
was straightforward. Handling overrides that didn't use generic names
was a little trickier.
To handle random override names (well rhel), I added some extra logic
in the config_generation script called "ORDER". This tells the scripts
which configs to lay down first and which one overrides it.
Through some testing, I realized I could simplify things and just create
an outer 'order' loop. This removed some duplicated code.
The other change is the 'skip_if_missing' flag. The overrides directory
will not mimic the baseline directory layout 100%. Ensure the baseline
config files are all there, but allow the overrides to have missing files.
Tested on my Fedora and my RHEL tree with success.
It was suggested that base-debug and base-generic were not good names
to use. Further discussion led to using configs/fedora for the base
config files and configs/rhel for any overrides.
This patch does a plain
mkdir configs/fedora
git mv configs/base-{generic,debug} configs/fedora
No code changes.
With the configs in the new place, update the scripts to find
them and utilize the base-generic and generic heirarchy to apply
configs and overrides.
Implement new process_configs.sh script that post-process the
config changes in a simple script and remove those commands
from the spec file. Add option flags to preserve functionality.
config_generation is a simple rename of baseconfig -> generic and
debugconfig -> debug and arm64 -> aarach64.
build_configs.sh is modified to find configs in generic and base-generic and
then apply base-generic first and if any generic files, apply those next. The
generic directory is used as an overrides and is expected to be empty for
Fedora initially.
kernel.spec is modified to use process_configs.sh instead of all the
commands in the spec file. Enabled spec options are translated to
script options. The config manipulation is moved to be grouped
with all config manipulation commands. This makes 'cd configs/' simpler.
Now all config scripts and executiion are done in configs/ directory.
v1 -> v2:
* the scripts were not working with SUBARCH correctly
* checkoptions was using wrong comparison file
* passing wrong kernel version to process_configs in spec file
v2 -> v3:
(incorporate Laura A's feedback)
* update README.txt
* fix build_configs.sh warnings
* Output info message on listnewconfig failure
As part of the config re-organization, put the scripts needed to create
the config files in the configs/ directory. At the top level create
symlinks for those scripts. This allows the kernel.spec file to find
the scripts it needs and work correctly.
No code changes.
As part of an effort to foster better cross collaboration with
internal Red Hat kernels, align the configs layout to match
that kernel. This will allow Red Hat engineers to provide easier
guidance on how to set various config options.
In addition, the scripts that process the config options will migrate
to the configs/ directory too in later patches. Future config
workflows will stage all work in the configs/ area.
A simple diff between the kernels will easily expose which config
options are different. Reading the comments in the file provides
guidance to Fedora to determine if that kernel should make a
similar change or not.
Rename debugconfig -> configs/base-debug
Rename baseconfig -> configs/base-generic
Rename configs/base-generic/arm/arm64 -> configs/base-generic/arm/aarch64
No code changes made.
The existing method of managing configuration files gets unweildy.
Changing individual lines in text files gets difficult without
manual organization. Switch to a method of configuration generation
that's inspired from the method used inside Red Hat. Each configuration
option gets its own file which are then combined to form the
configuration files. This makes confirming what's actually enabled much
easier.
