How is the Linux kernel tested ?

Question

How do the Linux kernel developers test their code locally and after they have it committed? Do they use some kind of unit testing, build automation? test plans?

Answer 1

In addition to above/below points, which emphasis more on the functionality testing, hardware certification testing and performance testing the Linux kernel.

A lot a testing actually happen through, actually scripts, static code analysis tools, code reviews etc. which is very efficient in catching bugs, which would otherwise break something in the application.

Sparse – An open-source tool designed to find faults in the Linux kernel.

Coccinelle is another program does matching and transformation engine which provides the language SmPL (Semantic Patch Language) for specifying desired matches and transformations in C code.

checkpatch.pl and other scripts - coding style issues can be found in the file Documentation/CodingStyle in the kernel source tree. The important thing to remember when reading it is not that this style is somehow better than any other style, just that it is consistent. this helps developers easily find and fix coding style issues, the script scripts/checkpatch.pl in the kernel source tree has been developed. This script can point out problems easily, and should always be run by a developer on their changes, instead of having a reviewer waste their time by pointing out problems later on.

Answer 2

How do the Linux kernel developers test their code locally and after they have it committed?

Do they use some kind of unit testing, build automation?

In classic sense of words, no.

E. g. Ingo Molnar is running the following workload: 1. build new kernel with random set of config options 2. boot into it 3. goto 1

Every build fail, boot fail, BUG or runtime warning is dealt with. 24/7. Multiply by several boxes, and one can uncover quite a lot of problems.

test plans?

No.

There may be misunderstanding that there is central testing facility, there is none. Everyone does what he wants.

Answer 3

LTP and Memtests are generally preferred tools.

Answer 4

adobriyan mentioned Ingo's loop of random config build testing. That is pretty much now covered by the 0-day test bot (aka kbuild test bot). A nice article about the infrastructure is presented here:Kernel Build/boot testing

The idea behind this set-up is to notify the developers ASAP so that they can rectify the errors soon enough. (before the patches make it into Linus' tree in some cases as the kbuild infrastructure also tests against maintainer's subsystem trees)

Answer 5

As far as I know, there is an automatically performance regression check tool(named lkp/0 day) running/funding by the Intel, it will test each valid patch sent to the mailing list and check the scores changed from different microbenchmarks such as hackbench, fio, unixbench, netperf, etc, once there is a performance regression/improvement, a corresponding report will be sent directly to the patch author and Cc related maintainers.

Answer 6

There also are:

MMTests which is collection of benchmarks and scripts to analyze the results

https://github.com/gormanm/mmtests

Trinity which is Linux system call fuzz tester

http://codemonkey.org.uk/projects/trinity/

Also the LTP pages at the sourceforge are quite outdated and the project has moved to GitHub https://github.com/linux-test-project/ltp