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 ﬁle 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 ﬁlesystem 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 conﬁgure 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.
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 http://klive.cpushare.com/).
If you want to start to use KLive, go to http://klive.cpushare.com/, where you can ﬁnd 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
A.3 Sending patches
If you want to submit a kernel patch ﬁxing a bug that you have found, ﬁrst read the file Documentation/SubmittingPatches in the kernel source three. In particular, pay attention to SECTION 3 - REFERENCES 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 ﬂy in an unpredictable ways, so you need to change their default conﬁgurations to send patches. For instance, in Thunderbird it usually is sufficient to install the extention for email encryption to get rid of such problems (anyway, if you want to use Thunderbird for sending patches, read http://mbligh.org/linuxdocs/Email/Clients/Thunderbird).
For sending a series of patches you can use the script available at http://www.aepfle.de/scripts/42 send patch mail.sh . If you do not have the time for ﬁguring out how it works yourself, follow the steps below:
make sure that you have mutt installed and fully functional (ie. it has to be able to send email messages out of your system, which is usually done with the help of an MTA, like sendmail or postfix, that needs to be working for this purpose)
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 ﬁle for your patchset, the format and contents of which should be the same as for the series ﬁle used by quilt (see Section 4.2). Finally, to send the patches run
Alternatively, you can send the series of patches with the help of the script available at http://www.speakeasy.org/∼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 ﬁle 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
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 ﬁle Documentation/HOWTO , so just read it if you want to know the answer.