Copyright © <2006> <Paolo Ciarrocchi>

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Introduction to Linux kernel development process

Written by Paolo Ciarrocchi, November 2005


Linux kernel development process is quite complex and not very well documented so I decided to try to summarize it in the hope to be useful for the community. 2.6.x kernels are the base stable releases released by Linus. The highest numbered release is the most recent. If regressions or other serious flaws are found then a -stable fix patch will be released (see below) on top of this base. Once a new 2.6.x base kernel is released, a patch is made available that is a delta between the previous 2.6.x kernel and the new one.

2.6.x kernels

2.6.x kernels are maintained by Linus Torvalds, it's development is as follow:

There a numbers of tools used by the community to measure the quality and the performance of a kernel. A couple of examples are:

But it's worth to mention what Andrew Morton wrote on lkml:

 "Nobody knows when a kernel will be released, because it's released
  according to perceived bug status, not according to a preconceived

2.6.x.y kernels, a.k.a -stable

Kernels with 4 digit versions are -stable kernels. They contain small(ish) critical fixes for security problems or significant regressions discovered in a given 2.6.x kernel.

This is the recommended branch for users who want the most recent stable kernel and are not interested in helping test development/experimental versions.

If no 2.6.x.y kernel is available, then the highest numbered 2.6.x kernel is the current stable kernel.

2.6.x.y are maintained by the "stable" team (stable at kernel dot org), are released almost every week.

Rules on what kind of patches are accepted, and what ones are not, into the "-stable" tree:

Procedure for submitting patches to the -stable tree:

Review cycle:

Review committee:

The -mm kernels

These are experimental kernels released by Andrew Morton.

The -mm tree serves as a sort of proving ground for new features and other experimental patches. Once a patch has proved its worth in -mm for a while Andrew pushes it on to Linus for inclusion in mainline.

Although it's encouraged that patches flow to Linus via the -mm tree, this is not always enforced. Subsystem maintainers (or individuals) sometimes push their patches directly to Linus, even though (or after) they have been merged and tested in -mm (or sometimes even without prior testing in -mm).

This branch is in constant flux and contains many experimental features, a lot of debugging patches not appropriate for mainline etc and is the most experimental of the branches described in this document.

These kernels are not appropriate for use on systems that are supposed to be stable and they are more risky to run than any of the other branches (make sure you have up-to-date backups - that goes for any experimental kernel but even more so for -mm kernels).

These kernels in addition to all the other experimental patches they contain usually also contain any changes in the mainline -git kernels available at the time of release.

The -mm kernels are not released on a fixed schedule, but usually a few -mm kernels are released in between each -rc kernel (1 to 3 is common).

The -git kernels

These are daily snapshots of Linus' kernel tree (managed in a git repository, hence the name).

These patches are usually released daily and represent the current state of Linus' tree. They are more experimental than -rc kernels since they are generated automatically without even a cursory glance to see if they are sane.

I hope you enjoy reading this article and I really deserve special thanks to Tony Luck and Jesper Juhl for their suggestions!!

Part of this article is from the document written by Jesper Juhl, you can find it here: