Linux Kernel Architecture

Mauerer runbapp06.tex V1 - 09/04/2008 6:14pm Page 1268

Appendix F: The Kernel Development Process..............................

Many of the topics discussed in this appendix are also addressed in the kernel source itself. A number of

files inDocumentation/relate to the style and mechanics of the development process. Coverage there is

quite comprehensive, so this appendix is just an overview of the essential ideas.

F.2 Kernel Trees and the Structure

of Development

The Linux kernel is a very dynamic piece of software,and one of the most striking aspects of its develop-

ment is that there isnodevelopment version! At least there’s no explicit, long-term development version

that’s managed by Linus Torvalds.

This used to be different in former times. Traditionally, kernel development was split into two different

branches. One branch contained stable kernel releases that were supposed to be used on production

systems, and they were identified by an even minor release number. Kernel branches 2.0, 2.2, and 2.4

were stable branches (with 2.0.x, 2.2.x, and 2.4.x being individual releases within that series), while 2.1,

2.3, and 2.5 were development releases — again with 2.5.x and so on as individual versions. The basic

idea of this approach was to allow new features and experimental patches to undergo a good deal of

testing and improvement, and once enough new features had been added and things had stabilized and

were perceived to be usable in practice, a new stable tree was opened. Ideally, distributors would then

pick the kernels from this release branch and integrate it into their distributions.

Unfortunately, things have not quite worked this way. A development cycle requiredyearsbefore a

new stable series could be opened, and this is a verylarge interval in the IT world. When a new piece

of hardware comes out, buyers do not usually want to wait for several years before the kernel picks

up support for it — or at least the kernel that most people use, the stable series. The same goes not just

for device drivers, but also for most new features. Therefore, distributors did port new features from

the development series back into their stable branch. And because every distribution has its own taste

about what is necessary and required, a different selection of features was back-ported, which led to

distribution kernels divergingmore and more from each other.

Since kernel series 2.6, a new development policy has been employed. There is only a single kernel

series, and the separation into stable and development trees does not exist anymore. Instead, a number

of more experimentally oriented kernel trees are used to test new features initially, and after a stabi-

lization and test period, they are directly merged into the main kernel series. The 2.6 tree is managed

by Linus Torvalds, who — as you might have heard — was the initial creator of Linux and set the ball

rolling. Kernels from this tree are usually referred to asvanilla kernels, to distinguish them from kernels

adapted by distributions based on their needs, or various experimental trees. The kernel series is denoted

asmainline.

Trees other than the main tree are conventionally identified by a postfix added to the version number. The

most important tree besides mainline is 2.6-mm, which is managed by Andrew Morton, and most patches

go through this tree before they are accepted into mainline 2.6. Many other subsystem-specific trees exist,

and they usually focus on one particular aspect of the kernel: 2.6-netfocuses on networking, and 2.6-rt

contains work related to real-time issues and interactivity problems, to just name two examples. There’s

also a-stablerelease that is used to incorporate important bug fixes for problems that appear after a

formal kernel release has taken place. Kernel trees come and go for various reasons: Developers might

have lost their interest to maintain them, or the reason for the tree might have vanished because the

problem it was concerned with has been solved by some means.