Linux Device Drivers

Chapter 4. Debugging Techniques

One of the most compelling problems for anyone writing kernel code is how to approach debugging. Kernel code cannot be easily executed under a debugger, nor can it be traced, because it is a set of functionalities not related to a specific process.

This chapter introduces techniques you can use to monitor kernel code and trace errors.

Debugging by Printing

The most common debugging technique is monitoring, which in applications programming is done by calling printf at suitable points. When you are debugging kernel code, you can accomplish the same goal with printk.

Printk

We used the printk function in earlier chapters with the simplifying assumption that it works like printf. Now it’s time to introduce some of the differences.

One of the differences is that printk lets you classify messages according to their severity by associating different ``loglevels,'' or priorities with the messages. You indicate the loglevel with a macro. For example, KERN_INFO, which we saw prepended to some of the earlier print statements, is one of the possible loglevels of the message. The loglevel macro expands to a string, which is concatenated to the message text at compile time; that’s why there is no comma between the priority and the format string in the examples below. Here are two examples of printk commands, a debug message and a critical message:

printk(KERN_DEBUG "Here I am: line %i\n", __LINE__); printk(KERN_CRIT "I'm trashed; giving up on %p\n", ptr); ...