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
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
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.
to post comments)