Linux Plumbers Conf 2011

One Line Summary

Abstract

Currently defconfigs are a bit of a mess. Looking in the arm architecture tree, there are hundreds of defconfigs which try to provide configs that can be used to generate working kernels for specific SoCs. Unfortunately these defconfigs are sometimes just full config files, making it difficult to see what specific options the SoC boards require beyond the config defaults. Additionally, each board maintainer not only picks the config options to enable the hardware being used, but also may select non-hardware related policy such as which filesystems should be enabled.

The resulting churn in the config space has resulted in flames from Linus, and proposals for possible solutions.

One solution is to utilize the Kconfig language and create fragments that provide meta-config options which will then select all the necessary config features for a specific bit of hardware.

In addition, these fragments can be combined with other Kconfig fragments, that provide policy decisions like what filesystems should be used and what generic drivers to support.

Many distributions already use a similar framework, assembling separate chunks of standard config fragments into a larger config, but this method has limitations. For instance, its possible for one config fragment to set CONFIG_FOO=y but another config fragment to set CONFIG_FOO=n. If these two fragments are combined, it creates a paradox that the kernel config system will not warn the user of. Instead distros/build systems then have to have post-merger validation scripts that check to make sure the resulting config has specific values they care about.

By using kconfig fragments, the kconfig language allows for consistency checks making sure that invalid combinations that produce paradoxes emit errors. Further, each distro uses their own custom build scripts to do this fragment merging, and checking steps. By pushing this functionality into the kernel build system itself, it would simplify and consolidate a chunk of what every distribution has to implement themselves.

However, before this will work, the Kconfig language has limitations that need to be resolved, such as:
1) Being able to select options from a choice block
2) Being able to select options as a module
3) Additionally to really simplify the Kconfig meta options, we will need to extend Kconfig to be able to do full dependency resolution, allowing a leaf config to be selected, and that in turn would select all the options which it depends on.

I have already implemented a proof of concept that tries to provide #1 above, and works around #2. I would like to talk about some of the lessons learned and get input on how to proceed.

Darren Hart (Intel – Yocto Project) will co-lead with me, as his work has run into this config fragment issue as well.

Tags

defconfig, kconfig, config management, kernel build systems

Speakers

• 

  Darren Hart

  Intel
  • Blog: http://www.dvhart.com/
  • Twitter: dvhart_

  Biography

  Darren Hart works for Intel’s Open Source Technology Center. He works on and
  around the Linux kernel in support of The Yocto Project. Previously, Darren led
  IBM’s real-time Linux development team from 2005-2010. He has presented on
  Real-Time Linux benchmarking at the Ottawa Linux Symposium in 2007 as well as
  the Linux Foundation: End User Summit in 2008. He presented his work on futex
  requeue PI support at LinuxCon and the Real-Time Linux Workshop in 2009. He
  presented his work on kernel assisted adaptive userspace mutexes at the 2010
  Linux Plumbers Conference.

• John Stultz

  Biography

  John Stultz has worked with the IBM LTC for just shy of ten years. He has worked on x86 server enablement, Enterprise Realtime Linux, and now as a member of the Linaro.org effort. In the Linux community, he has worked mostly as maintainer of the timekeeping subsystem, but has also worked on stability and scalability issues with the PREEMPT_RT patch, and most recently has begun looking at upstreaming Android functionality into the mainline kernel.