Wednesday, July 14, 2010

Some ideas about Linux Kernel unit testing

Going through the internet, it looks like the concept "Linux Kernel unit testing" is quite unpopular. People can't even find "linux kernel unit test" on Google (

The traditional kernel development and debugging tool is still probably "printk". I think if I get desperate about kernel debugging, I may try user-mode linux (UML) or KGDB, and also hope JTAG may provide some relief since it doesn't distinguish kernel vs. userspace that much.

Recently, KGDB has been mainlined into Linux Kernel, which allows remote debugging of the kernel like userspace code -- one can set breakpoints, step through, and watch variables in GDB. After playing with KGDB, it feels like it shouldn't be too difficult to hijack the kernel like what KGDB does, and add in some simple scaffolding for unit testing.

What I am thinking of is to create a service in the kernel like KGDB, which can communicate with a userspace command-line front-end, and let users test kernel function calls. So people can test functions in device drivers in a more interactive and controllable manner like in UML. Since all these can be done on device and the code can run in kernel, it should be quite convenient compared to setting up a KGDB connection between two devices or using other methods.

Some thoughts about how to implement this:

1) Specify what kernel functions can be exercised with the unit test framework. This can be done maybe by marking these functions with a macro (or tag) so some scanner can pick them up at compile time.

2) Use some C parser to generate stubs for these functions so that they can be called in a parameterized way (like RPC). CINT may be a good try for this.

3) Run a C interpreter (maybe still CINT) in the userspace to take unit-test C scripts or commands. For those kernel functions, it communicates to the kernel service to make these function calls, either in the current process context or simulates some interrupt context.

In this way, it should be very easy to unit-test new features/functions in device drivers, or other kernel code, so that hopefully it should make kernel development more efficient, and improve the code quality, by making it easier to debug code and try out new implementations.