Linux Kernel Architecture

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

Appendix F: The Kernel Development Process

F.2.1 The Command Chain

All active components of the kernel have amaintainerwho cares about development in a particular area.

Many maintainers, especially for larger components, are employed by various Linux vendors, but some

still work in their free time. A maintainer’s responsibility can range from controlling a single device

driver over some piece of infrastructure such as the kernel object mechanism to complete subsystems

such as the whole networking code, the block layer, or all code inarch/for a specific architecture. Main-

tainers are listed in the top-levelMAINTAINERSfile that comes with the kernel and contains several pieces

of information, as you can see here:

MAINTAINERS

IA64 (Itanium) PLATFORM

P: Tony Luck

M: [email protected]

L: [email protected]

W: http://www.ia64-linux.org/

T: git kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git

S: Maintained

In addition to the name of the maintainer and his (or her, but usually the former — kernel

development is not an actual hotbed of emancipation) e-mail contact, this file provides a

mailing list on which development in the respective area is discussed. Usually it’s much

preferred to ask questions and discuss things on this mailing list than to directly interact

with the maintainer. If the code is managed in a public-accessible version control repos-

itory, the location of the repository is specified — in this case, it’s a git repository that is

the preferred source code management system for many kernel developers (as discussed

in Appendix 2). Finally, the entry may specify a web page that contains information about

the subsystem, and the maintenance status. In principle, the entry can distinguish between

paid and unpaid tending of subsystems with the statesSupportedandMaintained,butthis

can often be a philosophical question. More important is the distinction between actively

maintained parts compared to code without a maintainer (Orphan), old and obsolete code

(Obsolete), and parts that receive little attention but are not completely unmaintained

(Odd Fixes).

Having maintainers for individual parts of the kernel that range from small portions such as drivers to

complete subsystems creates a loose hierarchy among developers. But again, there is no formal authority

that would determine this hierarchy — it all depends on the people who actually contribute code and

how much they trust each other. When code gets into the kernel, the usual (but not the only) way is to

traverse this hierarchy from bottom to top. A fix or new feature for a piece of code typically first goes

to the device- or subsystem-specific mailing list or the respective maintainer, and then progresses to

maintainers of higher levels, who pass it on to Andrew Morton’s-mmtree,^1 from which it might finally be

merged into the vanilla kernel tree. This process is often referred to asmerging upstream. However, that’s

only one possibility, and rules are by no means fixed.

F.2.2 The Development Cycle

One of the foremost reasons why an explicit development kernel series was abandoned was

the desire to accelerate the rate at which new features become available for production kernels

(^1) To reduce the number of merge conflicts in the-mmtree that can arise when new code is incompatible with other new code, another
development series named-nextis supposed to sort such issues out before any new code gets into the-mmtree.