Managing Linux Kernel Configurations with Config Fragments - Darren Hart, VMware [Open Source Summit EU 2018]

Especially in embedded, there are a lot of different kernel configurations to manage. How can we make this easier? Use the script.

There are 17209 Kconfig symbols in the kernel. Of course you use defconfigs, but still there are 3000 symbols in a defconfig. If you diff that from one version to the next, you end up with about 100 symbols that are different.

Kconfig file: see Documentation/kbuild/kconfig-language.txt. Every symbol has a type. If it has a prompt, it can be selected in menuconfig, otherwise only implicitly from some other symbol. depends and select force a config symbol to no resp. yes depending on some other symbol.

Your configs should be under revision control. A good commit message describes the problem and the intent. The change itself should do the intent, and nothing else. However, if you enable some option, the diff can be a whole lot larger, because some new symbols can become available. So just enabling one option can lead to a .config diff of 50-100 lines. Really, you want the diff to just show what you changed.

To make the diff clean, you can use a configuration fragment. E.g. arch/x86/configs/dell-smbios-wmi.config can be merged into an existing config with make defconfig_dell-smbios-wmi.config. What this does is to look at every config line in the starting config and the additional fragment, and report if it has changed. It will use the value of the latter fragment. At the end, an olddefconfig is done to resolve dependencies. The heavy lifting is done by the script. This script can also be called directly, and can also be used (and actually is used) in other Kconfig-based projects like Buildroot, uClibc, U-Boot, Busybox, Barebox.

How to organise your config fragments? There are four types of fragments: distro policies, machine architecture, board-specific things, and generic drivers for hotpluggable devices.

Currently, creating config fragments is manual. It would be nice if menuconfig could directly save a fragment. can silently fail: if a fragment enables something and it ends up not being enabled after the olddefconfig, this is not reported. Should be fixed.

It would also be nice to have something like an include. In yocto it’s done in a higher-level language.