Linux Kernel Testing and Debugging

Shuah Khan — Thu, 10 Jul 2014 16:00:00 +0000

Linux Kernel Testing Philosophy

Testing is an integral and important part of any software development cycle, open or closed, and Linux kernel is no exception to that. Developer testing, integration testing, regression, and stress testing have different individual goals, however from 1000 feet up, the end goal is the same, to ensure the software continues to work as it did before adding a new body of code, and the new features work as designed.

Ensuring software is stable without regressions before the release, helps avoid debugging and fixing customer and user found bugs after the release. It costs more in time and effort to debug and fix a customer found problem. Hence, testing is very important in the case of any software, not just the Linux kernel. Unlike closed and proprietary operating systems, the development process is open and is not locked down. This process is its strength as well as weakness. With several developers continuing to add new features, and fixing bugs, continuous integration and testing is vital to ensure the kernel continues to work on existing hardware as new hardware support and features get added. In the open source development, developers and users share the testing responsibility. This is another important difference between a closed development model and an open one.

Almost all Linux kernel developers, if not all, are very active Linux users themselves. There is no requirement that testers should be developers, however, users and developers that are not familiar with the new code could be more effective at testing a new piece of code than the original author of that code. In other words, developer testing serves as an important step in verifying the functionality, however, developer testing alone is not sufficient to find interactions with other code, features, and unintended regressions on configurations and/or hardware, developer didn't anticipate and didn't have the opportunity and resources to test. Hence, users play a very important role in the Linux Kernel development process.

So now that we understand the importance of continuous integration testing, we will go into the details of testing itself. Before we talk about testing, I would like to walk through the development process itself to help understand how it works and how the changes funnel into the mainline kernel.

3000+ kernel developers from around the world contribute to the Linux kernel. It is a 24hours, seven days a week, and 365 days of continuous development process that results in a new release once every 2+ months and several stable and extended stable releases. New development and current release integration cycles run in parallel.

For further reading on the development process, please refer to Greg Kroah-Hartman's presentation on the Linux Kernel Development.

Go to Full Article

Using qDebug

Johan Thelin — Thu, 15 Jul 2010 14:00:00 +0000

by Johan Thelin

GUI debuggers are the norm these days, however, I still feel the urge to do a little printf-debugging now and then. It might be wrong, it might be silly but it works.

I like to develop the odd graphical application and I like use Qt. For Qt, the nice Norwegian Trolls have provided the qDebug function. You can use it right away just like your old trusted printf:

if(complexStatement(x))
{
    qDebug("This code executes when x = %d", x);
    ...

This works great for integers and other basic types. But, take the fairly common class QColor. Your first thought would probably be to write out each component manually:

qDebug("Color is: %x, %x, %x",
       color.red(),
       color.green(),
       color.blue());

This can be rather tedious, and there are types which are complex to print. For instance, QString, stores unicode strings and uses implicit sharing to reduce copying overhead. This gives you quick internationalized applications, but you cannot easily print the thing. To the rescue: qPrintable.

qDebug("A string: %s", qPrintable(myString));

The qPrintable macro is handy, but you also need to be aware of its quirks. The returned const char pointer is only valid for that very call. I.e. you cannot store it and re-use it - that will most likely give you garbage output.

// Do not do this
const char *text = qPrintable(myString);
// ...
doSomething(text);

For those who refer to printf debugging as cout debugging, and those who like to have a more convenient API, I recommend including the QtDebug header. This way, you can stream most of Qt's types to qDebug. This means a more convenient API for when you need to print QColor values, etc:

qDebug() << color;

Printing using qDebug usually results in console output (you might have to add CONFIG += console to your project file to get output at all on some platforms). However, you can also install a message handler to present your messages in a GUI window, translate them, paint them in colors or just put them in a log file.

Go to Full Article