-1: A GUIDE TO THE KERNEL DEVELOPMENT PROCESS
+Introdution
+===========
-The purpose of this document is to help developers (and their managers)
-work with the development community with a minimum of frustration. It is
-an attempt to document how this community works in a way which is
-accessible to those who are not intimately familiar with Linux kernel
-development (or, indeed, free software development in general). While
-there is some technical material here, this is very much a process-oriented
-discussion which does not require a deep knowledge of kernel programming to
-understand.
-
-
-1.1: EXECUTIVE SUMMARY
+Executive summary
+-----------------
The rest of this section covers the scope of the kernel development process
and the kinds of frustrations that developers and their employers can
influence the direction of kernel development. Code contributed to the
Linux kernel must be made available under a GPL-compatible license.
-Section 2 introduces the development process, the kernel release cycle, and
-the mechanics of the merge window. The various phases in the patch
-development, review, and merging cycle are covered. There is some
+:ref:`development_process` introduces the development process, the kernel
+release cycle, and the mechanics of the merge window. The various phases in
+the patch development, review, and merging cycle are covered. There is some
discussion of tools and mailing lists. Developers wanting to get started
with kernel development are encouraged to track down and fix bugs as an
initial exercise.
-Section 3 covers early-stage project planning, with an emphasis on
-involving the development community as soon as possible.
+:ref:`development_early_stage` covers early-stage project planning, with an
+emphasis on involving the development community as soon as possible.
-Section 4 is about the coding process; several pitfalls which have been
-encountered by other developers are discussed. Some requirements for
+:ref:`development_coding` is about the coding process; several pitfalls which
+have been encountered by other developers are discussed. Some requirements for
patches are covered, and there is an introduction to some of the tools
which can help to ensure that kernel patches are correct.
-Section 5 talks about the process of posting patches for review. To be
-taken seriously by the development community, patches must be properly
-formatted and described, and they must be sent to the right place.
+:ref:`development_posting` talks about the process of posting patches for
+review. To be taken seriously by the development community, patches must be
+properly formatted and described, and they must be sent to the right place.
Following the advice in this section should help to ensure the best
possible reception for your work.
-Section 6 covers what happens after posting patches; the job is far from
-done at that point. Working with reviewers is a crucial part of the
-development process; this section offers a number of tips on how to avoid
-problems at this important stage. Developers are cautioned against
+:ref:`development_followthrough` covers what happens after posting patches; the
+job is far from done at that point. Working with reviewers is a crucial part
+of the development process; this section offers a number of tips on how to
+avoid problems at this important stage. Developers are cautioned against
assuming that the job is done when a patch is merged into the mainline.
-Section 7 introduces a couple of "advanced" topics: managing patches with
-git and reviewing patches posted by others.
-
-Section 8 concludes the document with pointers to sources for more
-information on kernel development.
+:ref:`development_advancedtopics` introduces a couple of "advanced" topics:
+managing patches with git and reviewing patches posted by others.
+:ref:`development_conclusion` concludes the document with pointers to sources
+for more information on kernel development.
-1.2: WHAT THIS DOCUMENT IS ABOUT
+What this document is about
+---------------------------
The Linux kernel, at over 8 million lines of code and well over 1000
contributors to each release, is one of the largest and most active free
better; the following text should help you - or those who work for you -
join our community.
-
-1.3: CREDITS
+Credits
+-------
This document was written by Jonathan Corbet, corbet@lwn.net. It has been
improved by comments from Johannes Berg, James Berry, Alex Chiang, Roland
This work was supported by the Linux Foundation; thanks especially to
Amanda McPherson, who saw the value of this effort and made it all happen.
-
-1.4: THE IMPORTANCE OF GETTING CODE INTO THE MAINLINE
+The importance of getting code into the mainline
+------------------------------------------------
Some companies and developers occasionally wonder why they should bother
learning how to work with the kernel community and get their code into the
point, vendors whose code is in the mainline and well maintained will be
much better positioned to get the new product ready for market quickly.
-
-1.5: LICENSING
+Licensing
+---------
Code is contributed to the Linux kernel under a number of licenses, but all
code must be compatible with version 2 of the GNU General Public License
-2: HOW THE DEVELOPMENT PROCESS WORKS
+.. _development_process:
+
+How the development process works
+=================================
Linux kernel development in the early 1990's was a pretty loose affair,
with relatively small numbers of users and developers involved. With a
processes to keep development happening smoothly. A solid understanding of
how the process works is required in order to be an effective part of it.
-
-2.1: THE BIG PICTURE
+The big picture
+---------------
The kernel developers use a loosely time-based release process, with a new
major kernel release happening every two or three months. The recent
release history looks like this:
+ ====== =================
2.6.38 March 14, 2011
2.6.37 January 4, 2011
2.6.36 October 20, 2010
2.6.35 August 1, 2010
2.6.34 May 15, 2010
2.6.33 February 24, 2010
+ ====== =================
Every 2.6.x release is a major kernel release with new features, internal
API changes, and more. A typical 2.6 release can contain nearly 10,000
As an example, here is how the 2.6.38 development cycle went (all dates in
2011):
+ ============== ===============================
January 4 2.6.37 stable release
January 18 2.6.38-rc1, merge window closes
January 21 2.6.38-rc2
March 1 2.6.38-rc7
March 7 2.6.38-rc8
March 14 2.6.38 stable release
+ ============== ===============================
How do the developers decide when to close the development cycle and create
the stable release? The most significant metric used is the list of
a little more than one development cycle past their initial release. So,
for example, the 2.6.36 kernel's history looked like:
+ ============== ===============================
October 10 2.6.36 stable release
November 22 2.6.36.1
December 9 2.6.36.2
January 7 2.6.36.3
February 17 2.6.36.4
+ ============== ===============================
2.6.36.4 was the final stable update for the 2.6.36 release.
for a longer period. As of this writing, the current long term kernels
and their maintainers are:
+ ====== ====================== ===========================
2.6.27 Willy Tarreau (Deep-frozen stable kernel)
2.6.32 Greg Kroah-Hartman
2.6.35 Andi Kleen (Embedded flag kernel)
+ ====== ====================== ===========================
The selection of a kernel for long-term support is purely a matter of a
maintainer having the need and the time to maintain that release. There
release.
-2.2: THE LIFECYCLE OF A PATCH
+The lifecycle of a patch
+------------------------
Patches do not go directly from the developer's keyboard into the mainline
kernel. There is, instead, a somewhat involved (if somewhat informal)
step. This approach invariably leads to frustration for everybody
involved.
-
-2.3: HOW PATCHES GET INTO THE KERNEL
+How patches get into the Kernel
+-------------------------------
There is exactly one person who can merge patches into the mainline kernel
repository: Linus Torvalds. But, of the over 9,500 patches which went
normally the right way to go.
-2.4: NEXT TREES
+Next trees
+----------
The chain of subsystem trees guides the flow of patches into the kernel,
but it also raises an interesting question: what if somebody wants to look
their way into linux-next some time before the merge window opens.
-2.4.1: STAGING TREES
+Staging trees
+-------------
The kernel source tree contains the drivers/staging/ directory, where
many sub-directories for drivers or filesystems that are on their way to
a proper mainline driver.
-2.5: TOOLS
+Tools
+-----
As can be seen from the above text, the kernel development process depends
heavily on the ability to herd collections of patches in various
quilt is the best tool for the job.
-2.6: MAILING LISTS
+Mailing lists
+-------------
A great deal of Linux kernel development work is done by way of mailing
lists. It is hard to be a fully-functioning member of the community
in the MAINTAINERS file packaged with the kernel source.
-2.7: GETTING STARTED WITH KERNEL DEVELOPMENT
+Getting started with Kernel development
+---------------------------------------
Questions about how to get started with the kernel development process are
common - from both individuals and companies. Equally common are missteps
Andrew Morton gives this advice for aspiring kernel developers
+::
+
The #1 project for all kernel beginners should surely be "make sure
that the kernel runs perfectly at all times on all machines which
you can lay your hands on". Usually the way to do this is to work
-3: EARLY-STAGE PLANNING
+.. _development_early_stage:
+
+Early-stage planning
+====================
When contemplating a Linux kernel development project, it can be tempting
to jump right in and start coding. As with any significant project,
communication can save far more time later on.
-3.1: SPECIFYING THE PROBLEM
+Specifying the problem
+----------------------
Like any engineering project, a successful kernel enhancement starts with a
clear description of the problem to be solved. In some cases, this step is
Only then does it make sense to start considering possible solutions.
-3.2: EARLY DISCUSSION
+Early discussion
+----------------
When planning a kernel development project, it makes great sense to hold
discussions with the community before launching into implementation. Early
avoided with some early discussion with the kernel developers.
-3.3: WHO DO YOU TALK TO?
+Who do you talk to?
+-------------------
When developers decide to take their plans public, the next question will
be: where do we start? The answer is to find the right mailing list(s) and
The task of finding the right maintainer is sometimes challenging enough
that the kernel developers have added a script to ease the process:
+::
+
.../scripts/get_maintainer.pl
This script will return the current maintainer(s) for a given file or
track down a maintainer for a specific piece of code.
-3.4: WHEN TO POST?
+When to post?
+-------------
If possible, posting your plans during the early stages can only be
helpful. Describe the problem being solved and any plans that have been
community informed as you go.
-3.5: GETTING OFFICIAL BUY-IN
+Getting official buy-in
+-----------------------
If your work is being done in a corporate environment - as most Linux
kernel work is - you must, obviously, have permission from suitably
-4: GETTING THE CODE RIGHT
+.. _development_coding:
+
+Getting the code right
+======================
While there is much to be said for a solid and community-oriented design
process, the proof of any kernel development project is in the resulting
quest.
-4.1: PITFALLS
+Pitfalls
+---------
-* Coding style
+Coding style
+************
The kernel has long had a standard coding style, described in
Documentation/CodingStyle. For much of that time, the policies described
80-column limit, for example), just do it.
-* Abstraction layers
+Abstraction layers
+******************
Computer Science professors teach students to make extensive use of
abstraction layers in the name of flexibility and information hiding.
replicating the same code throughout the kernel.
-* #ifdef and preprocessor use in general
+#ifdef and preprocessor use in general
+**************************************
The C preprocessor seems to present a powerful temptation to some C
programmers, who see it as a way to efficiently encode a great deal of
the compiler to perform type checking on the arguments and return value.
-* Inline functions
+Inline functions
+****************
Inline functions present a hazard of their own, though. Programmers can
become enamored of the perceived efficiency inherent in avoiding a function
irrelevant.
-* Locking
+Locking
+*******
In May, 2006, the "Devicescape" networking stack was, with great
fanfare, released under the GPL and made available for inclusion in the
corporate doors. But one large problem in particular was that it was not
designed to work on multiprocessor systems. Before this networking stack
(now called mac80211) could be merged, a locking scheme needed to be
-retrofitted onto it.
+retrofitted onto it.
Once upon a time, Linux kernel code could be developed without thinking
about the concurrency issues presented by multiprocessor systems. Now,
attention to concurrency will have a difficult path into the mainline.
-* Regressions
+Regressions
+***********
One final hazard worth mentioning is this: it can be tempting to make a
change (which may bring big improvements) which causes something to break
breaks? The best answer to this question was expressed by Linus in July,
2007:
+::
+
So we don't fix bugs by introducing new problems. That way lies
madness, and nobody ever knows if you actually make any real
progress at all. Is it two steps forwards, one step back, or one
user-space interfaces is always required.
-
-4.2: CODE CHECKING TOOLS
+Code checking tools
+-------------------
For now, at least, the writing of error-free code remains an ideal that few
of us can reach. What we can hope to do, though, is to catch and fix as
There are quite a few other debugging options, some of which will be
discussed below. Some of them have a significant performance impact and
should not be used all of the time. But some time spent learning the
-available options will likely be paid back many times over in short order.
+available options will likely be paid back many times over in short order.
One of the heavier debugging tools is the locking checker, or "lockdep."
This tool will track the acquisition and release of every lock (spinlock or
developers and users) in a deployed system; lockdep allows them to be found
in an automated manner ahead of time. Code with any sort of non-trivial
locking should be run with lockdep enabled before being submitted for
-inclusion.
+inclusion.
As a diligent kernel programmer, you will, beyond doubt, check the return
status of any operation (such as a memory allocation) which can fail. The
Other kinds of portability errors are best found by compiling your code for
other architectures. If you do not happen to have an S/390 system or a
Blackfin development board handy, you can still perform the compilation
-step. A large set of cross compilers for x86 systems can be found at
+step. A large set of cross compilers for x86 systems can be found at
http://www.kernel.org/pub/tools/crosstool/
embarrassment later.
-4.3: DOCUMENTATION
+Documentation
+-------------
Documentation has often been more the exception than the rule with kernel
development. Even so, adequate documentation will help to ease the merging
"cleanup" needs a comment saying why it is done the way it is. And so on.
-4.4: INTERNAL API CHANGES
+Internal API changes
+--------------------
The binary interface provided by the kernel to user space cannot be broken
except under the most severe circumstances. The kernel's internal
-5: POSTING PATCHES
+.. _development_posting:
+
+Posting patches
+===============
Sooner or later, the time comes when your work is ready to be presented to
the community for review and, eventually, inclusion into the mainline
directory.
-5.1: WHEN TO POST
+When to post
+------------
There is a constant temptation to avoid posting patches before they are
completely "ready." For simple patches, that is not a problem. If the
with the idea that they can help you drive the work in the right direction.
-5.2: BEFORE CREATING PATCHES
+Before creating patches
+-----------------------
There are a number of things which should be done before you consider
sending patches to the development community. These include:
always pays back the effort in short order.
-5.3: PATCH PREPARATION
+Patch preparation
+-----------------
The preparation of patches for posting can be a surprising amount of work,
but, once again, attempting to save time here is not generally advisable
done. When done properly, though, it is time well spent.
-5.4: PATCH FORMATTING AND CHANGELOGS
+Patch formatting and changelogs
+-------------------------------
So now you have a perfect series of patches for posting, but the work is
not done quite yet. Each patch needs to be formatted into a message which
subsystem name first, followed by the purpose of the patch. For
example:
+ ::
+
gpio: fix build on CONFIG_GPIO_SYSFS=n
- A blank line followed by a detailed description of the contents of the
detail in the SubmittingPatches document; what follows here is a brief
summary. Each of these lines has the format:
+::
+
tag: Full Name <email address> optional-other-stuff
The tags in common use are:
for addition without the explicit permission of the person named.
-5.5: SENDING THE PATCH
+Sending the patch
+-----------------
Before you mail your patches, there are a couple of other things you should
take care of:
Patches need good subject lines. The canonical format for a patch line is
something like:
+::
+
[PATCH nn/mm] subsys: one-line description of the patch
where "nn" is the ordinal number of the patch, "mm" is the total number of
-6: FOLLOWTHROUGH
+.. _development_followthrough:
+
+Followthrough
+=============
At this point, you have followed the guidelines given so far and, with the
addition of your own engineering skills, have posted a perfect series of
prevent the inclusion of your patches into the mainline.
-6.1: WORKING WITH REVIEWERS
+Working with reviewers
+----------------------
A patch of any significance will result in a number of comments from other
developers as they review the code. Working with reviewers can be, for
in mind, of course, that he may not agree with you either.
-6.2: WHAT HAPPENS NEXT
+What happens next
+-----------------
If a patch is considered to be a good thing to add to the kernel, and once
most of the review issues have been resolved, the next step is usually
afterward.
-6.3: OTHER THINGS THAT CAN HAPPEN
+Other things that can happen
+-----------------------------
One day, you may open your mail client and see that somebody has mailed you
a patch to your code. That is one of the advantages of having your code
-7: ADVANCED TOPICS
+.. _development_advancedtopics:
+
+Advanced topics
+===============
At this point, hopefully, you have a handle on how the development process
works. There is still more to learn, however! This section will cover a
number of topics which can be helpful for developers wanting to become a
regular part of the Linux kernel development process.
-7.1: MANAGING PATCHES WITH GIT
+Managing patches with git
+-------------------------
The use of distributed version control for the kernel began in early 2002,
when Linus first started playing with the proprietary BitKeeper
thing happening; putting up a git tree with unreviewed or off-topic patches
can affect your ability to get trees pulled in the future. Quoting Linus:
+::
+
You can send me patches, but for me to pull a git patch from you, I
need to know that you know what you're doing, and I need to be able
to trust things *without* then having to go and check every
sure that you have remembered to push those changes to the public server.
-7.2: REVIEWING PATCHES
+Reviewing patches
+-----------------
Some readers will certainly object to putting this section with "advanced
topics" on the grounds that even beginning kernel developers should be
-8: FOR MORE INFORMATION
+.. _development_conclusion:
+
+For more information
+====================
There are numerous sources of information on Linux kernel development and
related topics. First among those will always be the Documentation
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
-9: CONCLUSION
+Conclusion
+==========
Congratulations to anybody who has made it through this long-winded
document. Hopefully it has provided a helpful understanding of how the
--- /dev/null
+A guide to the Kernel Development Process
+=========================================
+
+Contents:
+
+.. toctree::
+ :numbered:
+ :maxdepth: 2
+
+ 1.Intro
+ 2.Process
+ 3.Early-stage
+ 4.Coding
+ 5.Posting
+ 6.Followthrough
+ 7.AdvancedTopics
+ 8.Conclusion
+
+The purpose of this document is to help developers (and their managers)
+work with the development community with a minimum of frustration. It is
+an attempt to document how this community works in a way which is
+accessible to those who are not intimately familiar with Linux kernel
+development (or, indeed, free software development in general). While
+there is some technical material here, this is very much a process-oriented
+discussion which does not require a deep knowledge of kernel programming to
+understand.
+
projects / GitHub / MotorolaMobilityLLC / kernel-slsi.git / commitdiff