Kernel Development with the menuconfig2 Build System
The menuconfig2 build system builds a kernel for the Balloon board like this:
- It downloads the kernel source from kernel.org or balloonboard.org (depending on the version)
It uses quilt to apply patches to the kernel source tree. The patches come from package/kernel/patches/<version>. The series of patches depends on the board variant selected, and is defined by a file package/kernel/patches/series-balloon3-<variant>. Wookey's QuiltHowto page is very helpful for explaining how this works.
It creates a .config file in the kernel source tree by copying a default config file from package/kernel/patches/<version>/balloon3config-<variant>. This file defines which options will be selected in the kernel.
It runs make in the kernel source tree to create the kernel and modules.
It does various postprocessing to create zImageBoot, zImageInitrd and modules.tgz in the build/kernel directory.
When it comes to modifying the kernel source, it is important to be aware of these things.
How to edit and rebuild the kernel safely
This is the process that CJ uses (as of 4 April 2011), having consulted with other members of the Balloon software team.
Build the standard kernel as above to make sure that everything is sane. If you want to customise any options in the kernel, use make kernel-menuconfig to set them.
Copy the .config file out of the build/kernel/linux-<version> directory into package/kernel/patches/<version>/balloon3config-<variant>. This makes sure that, if the build system decides to reapply a .config file to the kernel, you won't lose your changes. This can be a big time-waster if, for example, you build a kernel only to discover that it's missing support for your root filesystem.
If your edit is part of a patch, do quilt pop <patch-name> before editing, to make sure that the top of the patch stack contains the file you are editing.
Make sure that the file you are about to edit is already part of the current patch. (quilt add file if not). Forgetting this is very annoying, as is will eventually lose your changes and generates patches which won't apply for anyone else.
- Do your edits.
If your edit is part of a patch, do quilt refresh.
- Repeat for other patches if you need to.
It's fine to have a file be affected by more than one patch - managing that is what quilt is for, but you must be very careful which patch is current when making edits and doing refreshes, so that only relevant changes end up in each patch. A good example is balloon3.c, which contains code specific to the Balloon 3 board. It's often necessary to make changes to this to support new hardware, for example, in addition to developing the actual driver code in a different part of the source tree.
Before compiling, do quilt push -a to make sure all the patches are in place. The build system can't necessarily be relied upon to this for itself.
Important: do not do make in the kernel source tree. Instead, in the menuconfig2 checkout, do make there instead.
If the kernel compile process starts asking config questions, ctrl-C out of it. It's probably because .config has become inconsistent with the kernel source code. This can happen if you accidentally try to build without all the patches applied. Don't panic, simply make kernel-menuconfig, check your favourite options, save the config, exit and try make again.
Top tip: make sure the 'Rebuild Linux Kernel' option is set in make menuconfig, otherwise very little will happen.