There are 26 Kconfig symbols referenced in the files used for
configuration generation and in the shipped .config files that were
dropped in upstream v5.0-rc1. The references to these symbols can be
safely removed.
These symbols are:
CONFIG_BLK_WBT_SQ
CONFIG_CFQ_GROUP_IOSCHED
CONFIG_DEFAULT_CFQ
CONFIG_DEFAULT_DEADLINE
CONFIG_DEFAULT_NOOP
CONFIG_DRM_EXYNOS_IOMMU
CONFIG_IMX7_PM_DOMAINS
CONFIG_INTEL_RDT
CONFIG_IOSCHED_CFQ
CONFIG_IOSCHED_DEADLINE
CONFIG_IOSCHED_NOOP
CONFIG_MICROCHIP_KSZ
CONFIG_MICROCHIP_KSZ_SPI_DRIVER
CONFIG_MTD_PHYSMAP_OF_GEMINI
CONFIG_MTD_PHYSMAP_OF_VERSATILE
CONFIG_MTD_SPINAND_MT29F
CONFIG_MTD_SPINAND_ONDIEECC
CONFIG_QTNFMAC_PEARL_PCIE
CONFIG_SCSI_MQ_DEFAULT
CONFIG_SND_AM33XX_SOC_EVM
CONFIG_SND_DAVINCI_SOC
CONFIG_SND_DAVINCI_SOC_GENERIC_EVM
CONFIG_SND_DAVINCI_SOC_I2S
CONFIG_SND_DAVINCI_SOC_MCASP
CONFIG_SND_DAVINCI_SOC_VCIF
CONFIG_SND_EDMA_SOC
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Kernel package tips & tricks.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The kernel is one of the more complicated packages in the distro, and
for the newcomer, some of the voodoo in the spec file can be somewhat scary.
This file attempts to document some of the magic.
Speeding up make prep
---------------------
The kernel is nearly 500MB of source code, and as such, 'make prep'
takes a while. The spec file employs some trickery so that repeated
invocations of make prep don't take as long. Ordinarily the %prep
phase of a package will delete the tree it is about to untar/patch.
The kernel %prep keeps around an unpatched version of the tree,
and makes a symlink tree clone of that clean tree and than applies
the patches listed in the spec to the symlink tree.
This makes a huge difference if you're doing multiple make preps a day.
As an added bonus, doing a diff between the clean tree and the symlink
tree is slightly faster than it would be doing two proper copies of the tree.
Build logs.
-----------
There's a convenience helper script in scripts/grab-logs.sh
that will grab the build logs from koji for the kernel version reported
by make verrel
Config hierarchy.
-----------------
Instead of having to maintain a config file for every arch variant we build on,
the kernel spec uses a nested system of configs. Each option CONFIG_FOO is
represented by a single file named CONFIG_FOO which contains the state (=y, =m,
=n). These options are collected in the folder base-generic. Architecture
specific options are set in nested folders. An option set in a nested folder
will override the same option set in one of the higher levels.
The individual CONFIG_FOO files only exist in the pkg-git repository. The RPM
contains kernel-foo.config files which are the result of combining all the
CONFIG_FOO files. The files are combined by running build_configs.sh. This
script _must_ be run each time one of the options is changed.
Example flow:
# Enable the option CONFIG_ABC123 as a module for all arches
echo "CONFIG_ABC123=m" > configs/base-generic/CONFIG_ABC1234
# enable the option CONFIG_XYZ321 for only x86
echo "# CONFIG_XYZ321 is not set" > configs/base-generic/CONFIG_XYZ321
echo "CONFIG_XYZ321=m" > configs/base-generic/x86/CONFIG_XYZ321
# regenerate the combined config files
./build_configs.sh
The file config_generation gives a listing of what folders go into each
config file generated.
Debug options.
--------------
This is a little complicated, as the purpose & meaning of this changes
depending on where we are in the release cycle.
If we are building for a current stable release, 'make release' has
typically been run already, which sets up the following..
- Two builds occur, a 'kernel' and a 'kernel-debug' flavor.
- kernel-debug will get various heavyweight debugging options like
lockdep etc turned on.
If we are building for rawhide, 'make debug' has been run, which changes
the status quo to:
- We only build one kernel 'kernel'
- The debug options are always turned on.
This is done to increase coverage testing, as not many people actually
run kernel-debug.
The debug options are managed in a separate heierarchy under base-debug. This
works in a similar manner to base-generic. More deeply nested folders, again,
override options. The file config_generation gives a listing of what folders
go into each config file generated.