Linux Kernel Architecture

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

Appendix F: The Kernel Development Process

Content is provided free of charge one week after it has been published initially, but the most

current information is available to subscribers only. Since the fee is small, I highly recommend

that you subscribe as soon as possible!^3

❑ Full-scale change logs of the kernel can easily take a number of megabytes in size. Although

they meticulously register every commit that was accepted since the last release, it is practically

not possible to get a broad overview of what has happened in kernel development. Thankfully,

http://www.linuxnewbies.netprovides less-detailed change logs that put more emphasis on the big

picture than small individual details.

❑ The Linux Foundation provides a ‘‘weather forecast’’ service that tries to predict which patches

and features are going to be accepted into future kernel versions. This is as close to a road map as

the Linux kernel can get, and provides valuable information on the direction that development

is heading in. The URL iswww.linux-foundation.org/en/Linux_Weather_Forecast.

F.3 The Structure of Patches

Kernel developers expect that good patches fulfill certain fixed criteria. Although this puts more

load onto the preparer of a patch, it makes things much easier for maintainers, reviewers, and

testers because less time is required to understand individual changes if they all follow iden-

tical conventions. The kernel includes detailed instructions on how to prepare patches, which

can be found inDocumentation/SubmittingPatches. This section summarizes the essential

points, but be sure to read the wholeSubmittingPatchesdocument before you send code to

any maintainer or mailing list. Further advice is given in Andrew Morton’s ‘‘The Perfect Patch’’

document, available onwww.zip.com.au/~akpm/linux/patches/stuff/tpp.txt, and on the web site

linux.yyz.us/patch-format.html.

First and foremost, it is essential to break larger changes into pieces that are easier to digest than a single

patch that touches 10 million files across 50,000 subdirectories. A patch should do one logical change

to the source code, even if that means that more than one patch in a patch series changes the same file.

Ideally, patches should bestackable— that is, it should be possible to apply them independent of each

other. However, owing to the nature of changes, this is not always possible, and in this case, the correct

temporal ordering of the patches should be documented.

In principle, patch series can be created by hand usingdiffandpatchas described in

Appendix 2. This can become quite tedious after a while, but thequilttoolbox available on

http://savannah.nongnu.org/projects/quiltprovides some relief here by automating most of the

process of managing patch stacks.

F.3.1 Technical Issues

As for the technical format of a patch, notice that aunifiedpatch that includes information on the C

functions being changed is required. Such a patch can be generated usingdiff -up. If the patch adds

new files or concerns files in multiple subdirectories, thendiff -uprNmust be used to account for these

cases. Appendix 2 discusses what the resulting patch looks like and which information it contains.

(^3) And, no, I have no commercial interests nor any relation to LWN whatsoever. But the site is just awesome.