Appendix A

A.1 Test system

Ideally, your test system should be separate from the production one used for normal work. In particular, you should not mount any production file systems from within the test environment. This way you can avoid damaging or losing your production data if there is a serious bug, leading to data losses, in the tested kernel. Of course, if the tested kernel damages the test environment, you ought to notify the kernel developers of the problem.

Fortunately, you need not boot the test system in order to reconfigure it or install a new kernel on it. Namely, you can mount the test system’s root filesystem using a temporary mount point (eg. /mnt) and go to it using chroot. Then, you will be able to prepare the new kernel, compile it and install it (that should better be done with the help of a script automating the entire process), while using the computer for normal work. Next, when you have some time, you can boot the test system and run some tests on it.

It is best to configure the test system with your convenience in mind, as it should not require you to do very much additional work. For this reason, the distribution installed on it should allow you to compile and test the kernel easily. It should also allow you to test the new functionality of the kernel, so it ought to contain contemporary versions of kernel-related tools and libraries. The test branch of Debian is one of such distributions, because it contains current versions of the most important utilities as well as older versions of gcc, which are sometimes useful (unfortunately, some kernel developers only check if their code is compiled correctly by the gcc available in their favorite distribution). In turn, Fedora Core supports SELinux very well and it allows one to try all of the new functionality offered by the latest kernels.

A.2 KLive

KLive is a tool allowing the kernel developers to learn the amount of testing that given kernel version has received. Why is it worthy of using? Well, that is how Linus Torvalds announced the 2.6.15-rc5 kernel:

"There’s a rc5 out there now, largely because I’m going to be out of email contact for the next week, and while I wish people were religiously testing all the nightly snapshots, the fact is, you guys don’t."

The developers are not clairvoyants and they do not know how many people have tested given version of the kernel and for how long. Thus, if everything works well and no one reports any problems, the maintainer of given kernel tree has no idea if the latest version of it have been tested at all. That is where KLive might help, as it makes your test system report the kernel version, uptime and some additional information to a server which collects this information and produces some statistics based on it (they are available from the project’s web page at

If you want to start to use KLive, go to, where you can find out how it works and how to install it. The installation, by the way, is very simple, as you only need to install some packages needed by KLive, that should be available in any contemporary Linux distribution, and run

# sh --install

A.3 Sending patches

If you want to submit a kernel patch fixing a bug that you have found, first read the file Documentation/process/submitting-patches.rst in the kernel source tree. In particular, pay attention to the REFERENCES section containing references to the documents that you should get familiar with before sending the patch.

You also will need to know how to prevent your mail client from mangling patches by adding or removing white space, or by applying the quoted printable encoding to them. Some mail clients, like Mozilla Thunderbird, tend to modify white space on the fly in an unpredictable ways, so you need to change their default configurations to send patches. For instance, in Thunderbird it usually is sufficient to install the extension for email encryption to get rid of such problems (anyway, if you want to use Thunderbird for sending patches, read

For sending a series of patches you can use the script available at send patch . If you do not have the time for figuring out how it works yourself, follow the steps below:

Now, you need to create the description file that will be sent as the first message in the series (ie. the one with [PATCH 0/x] in the subject line). Its format should be as follows:

Subject: <Title of the series of patches>
To: <destination email address>
CC: <comma separated list of additional destination email addresses>
Description of patches in the series, diffstat etc.

Next, similar header has to be added at the beginning of each patch and you need to create a series file for your patchset, the format and contents of which should be the same as for the series file used by quilt (see Section 4.2). Finally, to send the patches run

$ -d <description file> -s <series file>

Alternatively, you can send the series of patches with the help of the script available at∼pj99/sgi/sendpatchset, having the advantage that mutt and the MTA are not needed for it to work. It is sufficient to create a special control file of the following format:

SMTP: adress of your SMTP server
From: your name <your email address>
To: Destination <destination email address>
Cc: Someone else <email address>
Cc: Someone else <email address>
Subject: [PATCH 1/n] Title of the first patch
File: path to the first patch file
Subject: [PATCH n/n] Title of the nth patch
File: path to the nth patch file

(note that the < and > braces above are mandatory). Next, to send the patches, you only need to run $ sendpatchset control

A.4 How to become the kernel developer?

This question appears on LKML from time to time (we are not going to answer it here) and for this reason Greg Kroah-Hartman has written a short document about it. It is distributed along with the kernel sources, in the file Documentation/process/howto.rst , so just read it if you want to know the answer. :-)

KernelNewbies: Linux_Kernel_Tester's_Guide_Appendix_A (last edited 2021-01-14 18:08:17 by RandyDunlap)