Contributing to the Linux Kernel—The Linux Configuration
At this point, you have your patch surrounded by defines which correspond to configuration options. You can now toggle the use of your patch in the configurator. The hardest part is done, now we just need to fill in some loose ends.
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.
The final and often overlooked portion of a patch is the help file that must accompany the configuration option. The file in question is Documentation/Configure.help. The format of that file is something like this (or see the attached example):
<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).
You should be done at this point. Before you can send off your patch for submission, it is wise to compile it both enabled and disabled and make sure both kernels work properly. If there are dependencies, make sure they are working correctly and that all the options you would expect to have, you have, and vice versa. And finally, you should send your patch to the kernel list and request bug reports before you announce it as being done to Linus and the gang, or be prepared for a heavy dose of reality, especially if you made changes that impact architectures you don't actually have.
CML2: A New, Easier Kernel Configuration System by Eric S. Raymond
Joseph Pranevich (firstname.lastname@example.org) is an avid Linux geek, and while not working for Lycos, enjoys writing (all kinds) and working with a number of open-source projects.
|HPC Cluster Grant Accepting Applications!||Jan 28, 2015|
|Sharing Admin Privileges for Many Hosts Securely||Jan 28, 2015|
|Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform||Jan 23, 2015|
|Designing with Linux||Jan 22, 2015|
|Wondershaper—QOS in a Pinch||Jan 21, 2015|
|Ideal Backups with zbackup||Jan 19, 2015|
- Sharing Admin Privileges for Many Hosts Securely
- HPC Cluster Grant Accepting Applications!
- Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform
- Internet of Things Blows Away CES, and it May Be Hunting for YOU Next
- Designing with Linux
- Ideal Backups with zbackup
- Wondershaper—QOS in a Pinch
- Slow System? iotop Is Your Friend
- diff -u: What's New in Kernel Development
- Hats Off to Mozilla
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane