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?
+1
A:
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.
adobriyan
2010-07-05 06:59:56
I must ask, source?
carl
2010-07-05 07:06:34
Given the existence of sites such as [this](http://ltp.sourceforge.net/) and [this](http://test.kernel.org/tko/) I also would question the validity of this answer.
Dean Harding
2010-07-05 07:12:38
Source to what statement exactly?If it's about Ingo's setup, it's common knowledge on linux-kernel.
adobriyan
2010-07-05 08:41:05
I think the core of adobriyan's answer "there is central testing facility, there is none." is about right. However different groups do varying levels of testing, it's not as though the kernel is completely untested.
stsquad
2010-07-05 11:08:14
I think both SUSE and RedHat in addition to testing their own kernels, test vanilla often. There is no central testing per se, but there is a testing going on nevertheless - by the major users of Linux. Otherwise the comment stands. Were it written less sarcastically I would have even modded it up.
Dummy00001
2010-07-05 23:09:48
Errr, do you all people realize that Alexey Dobriyan _is_ a Linux kernel developer?
ninjalj
2010-08-01 20:40:42
A:
I would imagine they use virtualization to do quick tests, something like QEMU, VirtualBox or Xen, and some scripts to perform configurations and automated tests.
Automated testing is probably done by trying either many random configurations or a few specific ones (if they are working with a specific issue). Linux has a lot of low-level tools (such as dmesg) to monitor and log debug data from the kernel, so I imagine that is used as well.
emcee
2010-07-05 07:05:02
+4
A:
The linux kernel has a heavy emphasise on community testing.
Typically any developer will test their own code before submitting, and quite often they will be using a development version of the kernel from Linus, or one of the other unstable/development trees for a project relevant to their work. This means they are often testing both their changes and other people's changes.
There tend not to be much in the way of formal test plans, but extra testing may be asked for before features are merged into upstream trees.
As Dean pointed out, there's also some automated testing, the linux test project and the kernel autotest.
Developers will often also write automated tests targetted to test their change, but I'm not sure there's a (often used) mechanism to centrally collect these adhoc tests.
It depends a lot on which area of the kernel is being changed of course - the testing you'd do for a new network driver is quite different to the testing you'd do when replacing the core scheduling algorithm.
JosephH
2010-07-05 15:26:27
+1, half the battle is simply not breaking something that drivers depend on, hence the persistence of the BKL over the years. The other thing to consider is testing many sub systems on many different architectures, which is only practically feasible with the kind of community abuse, err testing, that Linux receives.
Tim Post
2010-07-05 15:52:29
A:
Its not very easy to automate kernel testing. Most Linux developers do the testing on their own, much like adobriyan mentioned.
However, there are a few things that help with debugging the Linux Kernel:
- kexec: A system call that allows you to put another kernel into memory and reboot without going back to the BIOS, and if it fails, reboot back.
- dmesg: Definitely the place to look for information about what happened during the kernel boot and whether it works/doesn't work.
- Kernel Instrumentation: In addition to printk's (and an option called 'CONFIG_PRINTK_TIME' which allows you to see (to microsecond accuracy) when the kernel output what), the kernel configuration allows you to turn on a LOT of tracers that enable them to debug what is happening.
Then, developers usually have others review their patches. Once the patches are reviewed locally and seen not to interfere with anything else, and the patches are tested to work with the latest kernel from Linus without breaking anything, the patches are pushed upstream.
Vanwaril
2010-07-21 15:01:56