Learn the correct procedures for submitting a patch to the kernel.
by Joseph Pranevich
The Linux kernel has always been one of the most prized gems in the Open Source community. Based around a philosophy of shared resources through modularity, it somehow is both well-written and written by committee. (Or, at least, by many individuals and teams which argue/agree over features.) One of the methods by which Linux keeps everything neat and modular is the kernel configuration system, often referred to as config, menuconfig and xconfig. These are the scripts that an installer of a source kernel must run in order to set up the kernel options, but you probably know that if you are reading this. On the outside, these look like three very separate programs with completely separate interfaces. In reality though, all three draw from the same fundamental rules that many programmers of the Linux kernel must know in order to spread their work or even to submit their patches to Linus. It is this fundamental system that gives Linux users the options they need to design a Linux system based on their needs.
Since the Linux kernel is an open-source project, it obviously accepts submissions from its users for new features. Often, however, programmers with the desire and the know-how to add features to the Linux kernel choose not to for a variety of reasons. In this article, I hope to clear up some of the mysteries surrounding the kernel configuration system that may be hindering users and keeping them from becoming developers. Every brain counts in open-source efforts, and every programmer who adds his or her changes into the kernel makes the kernel more robust for the rest of us.
The first thing to make sure of when you do this is to be consistent. In a system as complicated as the Linux kernel, a little bit of consistency can save a lot of headaches later. You should look in Documentation/Configure.help for similar options and check to see if they have a common prefix (after CONFIG_, of course). For example, all block device options start with CONFIG_BLK_DEV_. This is relatively easy to change later, of course.
Once the name is selected, you should make #ifdef...#endif blocks around portions of the code that your patch changes (having a Linus tree around when you do this helps, as you can diff it and easily see what you changed). If you removed existing code, you'll need to integrate the #else blocks from the real tree, unless you were smart enough to keep them around while you were writing your patch. (I usually use the construct ``#if 0'' early in the programming stage.) At this point, compiling the kernel should work, and your option will be correctly disabled and we can continue to the next step. If it doesn't work or portions of your patch are still present, you obviously need to go back and double-check your diffs.
For the purposes of my example, I would choose the name CONFIG_RANDOM for the option. The random devices are character devices, and at the time of this writing, there was no CONFIG_CHAR_( or similar) prefix in common use.
bool 'Random driver support' CONFIG_RANDOM(Please note here that a' is used as the quote character. This can be easy to miss.)
If your configuration option relies on another to be set, this model becomes more complicated. You will need to surround your options with an if ... fi block that tests the prerequisite option. There are a number of examples in the assorted configuration files to help you with this process; when in doubt, copy. One final word: you should be aware that this file is used not only to generate the selection lists in the configuration processes, but also to generate the include/linux/autoconf.h file. In order to preserve the readability of that file, you should be careful that options you add do not come after other subheadings or the configuration option will not appear in the right place when that file is generated. (Of course, it will still work no matter where it is in the file, but for readability, this is something to consider.)
As you have probably noticed if you have used Linux on more than one architecture, there are different options for each of the different platforms. Thus far, you have not concerned yourself with making much of that distinction, but now it is time. In order to modify the defconfig file the right way, you'll need to take a couple of steps. First, you should back up your .config file with your personal configuration settings. Replace that file with a copy of arch/<whatever>/defconfig and rerun the configurator. Select whatever option you would like to be the default for your config option, and save that file. Replace defconfig with the new .config and replace the old one. You now have a new default configuration file built for your architecture.
If your patch works for multiple architectures (for example, it's a generic network protocol type or something that is generally applicable), you'll want to make default config files for all the architectures it supports. This can be done most easily be repeating the steps above, except first changing the ARCH line in the source Makefile to reflect the architecture you are building the config file for.
<description> <variable name> <help file>In addition, it should be noted that there must be an extra blank line between config files, and newer kernels support having blank lines in the help text itself, provided that the blank line actually contains a space or other white space.
It is highly advised that you attempt to locate a portion of this file that roughly corresponds to what your option is for. Often, but not always, options in similar places in the configuration menus will have similar places in the help file, and that can serve as a helpful indication as to the best place to put your particular piece. If you still do not know where to put everything, I advise sending e-mail to the current help maintainer with a question and a brief description of what your patch does (maybe even include the help text you would like to have added).
CML2: A New, Easier Kernel Configuration System by Eric S. Raymond
Joseph Pranevich (jpranevich@lycos.com) is an avid Linux geek, and while not working for Lycos, enjoys writing (all kinds) and working with a number of open-source projects.