KS2012: ARM: Toward a single kernel image

Over the last two or three years, the ARM Linux development community has been working toward the goal of having a single kernel image that can boot on multiple ARM platforms. One of the preconditions for creating such an image is the elimination of duplicate header files in the tree, which has mostly been completed, Arnd Bergmann said. The biggest problem now is that platform-specific header files are included into the drivers. When building a multi-platform kernel, which of the platform's headers does the driver get?

Drivers really shouldn't be including the platform-specific headers (from the mach-* directories), but many do. There are 300-350 header files under mach-* that are currently used by drivers. There are a number of reasons why this happened: various frameworks were missing for things like power domains, it was easier to add a header file into a directory that is owned by the platform rather than arguing about getting it into a more generic place, and so on. mach-* became a dumping ground, Bergmann said.

He has a patch that would rename all of those include files so that the platform name becomes the prefix of the header filename. It also changes the references in the driver source files to include the proper file. That doesn't solve the dumping ground problem, it simply works around it so that multi-platform kernels can be built.

Bergmann said that ARM maintainer Russell King was not in favor of that approach. Instead, King would like to use the single zImage as something of a carrot to get the sub-architecture maintainers to clean things up. King thinks that the platform-specific directories should not be in the include path for building the drivers, which would force the issue.

One participant suggested that there aren't that many things to fix per platform, but Bergmann disagreed. There is a lot of work to do for some platforms, including some of those that are the "most interesting", such as Samsung and OMAP.

Magnus Damm suggested that checkpatch be extended to complain about drivers that include files from the platform-specific directories. That would help to ensure new drivers were not including improper headers. But, Bergmann said that he didn't use checkpatch before accepting patches, though he admitted that maybe he should do so. Paul Walmsley said that OMAP requires patches to be checkpatch clean (other than 80 column warnings) before accepting them.

Rob Herring has an alternative approach that is likely to be more acceptable to King. He has reworked the header files without renaming them, which reduces the code churn. There are still three problematic header files, though: uncompress.h, gpio.h, and timex.h. But Herring can build a number of platforms into a single zImage without using Bergmann's renaming trick.

Bergmann wanted to see if the assembled ARM developers could come to a conclusion on the right approach. Basically, either of the two header file rearrangement solutions could solve the technical problems in building multi-platform kernels, but they wouldn't force the cleanups that King would like to see happen. In general, most in the room seemed in favor of getting things cleaned up so that there is a clean separation between drivers and platforms—as King has advocated.

It is a perfect task for Linaro, as Walmsley pointed out. It was noted that the worst offenders are all Linaro members, which makes it align well with the organization's mission. Bergmann said that Linaro has some people working on multi-platform kernels who could potentially work on the project.

The conversation turned toward how to get there. Tony Lindgren said that he could do an initial pass on OMAP in the next week or so to start to figure out how to fix up the drivers. There are certain frameworks (common clock, sparse IRQ) that drivers and platforms will be required to use in order to be included in single zImage effort. In addition, SMP-capable platforms will need to use Marc Zyngier's smp_ops framework, which Bergmann will be reworking and posting in the near future.

Using Herring's header file changes, but not renaming all the mach-* include files, is the basic approach chosen. That will still use some parts of Bergmann's changes. In the end, it will still be a fair amount of code churn, so there was discussion of how to manage those changes in the arm-soc tree. The intent is to try to make it work for the 3.7 cycle, with a fallback to making those changes the base patch for the arm-soc tree for 3.8 if it gets too messy.

Bergmann also demonstrated the Kconfig changes that he has made so that kernel developers can enable multiple platforms in their kernel builds. Once multi-platform support is selected, then one or more of the ARM architecture versions (v4-7) can be chosen. For each architecture, possible SoCs are listed and, if none is chosen, a default is picked. In addition, SoC maintainers can decide whether to expose individual boards for selection. Those Kconfig changes could be used as the basis for building multi-platform kernels once the rest of the work is done.

The header file renaming script will still be useful, Bergmann said, to help figure out the include file dependencies, which drivers require which platforms, and so on. Using shell tools and grep on a renamed tree can give some insights into how things are currently organized. That will help as these driver problems are unwound on the way to a multi-platform ARM kernel image.