Using kernel config fragments

   |    Posted by:    |    Comments: 0

At Softcrates we maintain a lot of kernel trees for our customers and are constantly trying to improve our processes to be efficient and spent the less possible time when updating the kernel to newer versions. One problem with Linux embedded platforms is that silicon vendors don't have a complete support for their chips in the mainline kernel. Instead they fork the kernel and create a vendor tree with all the support.

This means that to use the mainline kernel on a product there is a set of vendor patches that have to be carried from kernel version to version. This process is particularly difficult with the Linux kernel since it does not have an internal stable API by design.

Also, since the kernel is used on very different hardware platforms (from tiny embedded devices to supercomputers) and support dozens of architecture its build system configuration is not trivial.

This article does not pretend to be an introduction to the Linux kernel build system (Kbuild) and its configuration (Kconf) but only explain how we manage our clients custom kernel configurations. For an introduction to Kbuild and Kconf you can refer to the Linux kernel documentation files or this Linux journal article:

There are different options to manage the kernel configuration.

1- Create a custom kernel default config:

There are default kernel config in the kernel under arch/<arch>/configs for each architecture and hardware platform that should have good default and include all the needed configuration options to make the platform to work.

So, an approach is to use this file as a base and add the needed config options specific to your platform or product. This has the advantage that you can tailor the config and make it very specific to your needs but has the disadvantage that any changes to the default config for the platform will be missed.

Since the kernel doesn't have an stable API, sometimes is not evident what config options were introduced and what is missing to make a new kernel to work with your old kernel configuration. So this approach is not recommended unless strictly necessary and the default config for the platform is constantly monitored for new config changes.

2- Add custom kernel config options to the platform default config

The second approach is to change the default platform kernel config directly. This has the advantage that any changes to the default config made on the mainline kernel will not be missed but has the disadvantage that since your changes are not visible there may be conflicts between the custom config and what is changed in mainline.

3- Using kernel config fragments and script

The recommended approach and how we manage our kernel configurations in Softcrates is to have all the custom config options in different files and merge them along with the platform default kernel config using the script.

For example, let's suppose that you are using an OMAP3 platform and need a set of kernel config to enable display on your board. These options are not in the default arch/arm/configs/omap2plus_defconfig so you need a way to manage that difference.

So what you do is to create a myboard.conf file that contains the needed kernel config options:


And then use the script to merge the default OMAP kernel configuration with your custom options:

./scripts/kconfig/ arch/arm/configs/omap2plus_defconfig
../myboard.conf has different options so you can see what kernel options on your fragments file are redundant (e.g: are already present on the default config), use allnoconfig or allyesconfig as default for
not present kernel options, etc.

Execute ./scripts/kconfig/ -h to see all the options.

We hope this blog entry was useful and let you improve your processes as we love to do at Softcrates.

Happy hacking!

Leave a comment

Make sure you enter the (*) required information where indicated. HTML code is not allowed.