How do *you* debug device drivers?

[Robert Stroud]

<This line is a figment of your imagination>

I have found lots of printf's very effective especially since the
Unix workstation I debug my kernels on has a habit of stopping dead
(or crashing unrecoverably into an incomprehensible microcode debugger)
whenever there is a problem. I seriously think that this sort of total
failure mode is a useful debugging aid as well (well nearly seriously :-)!

Of course, printf's are very unscientific, but there are a couple of useful
techniques you can use to improve things. Using a macro it is very easy
to introduce the idea of a debugging level - the information is only
printed if the level is higher than the argument to the macro. For example,

# define dbgprint(x,y)  if (level > x) printf(y)

where y could be a list of arguments, (unfortunately this means that you need
versions of the macro for 0,1,2 etc  arguments), and level is either a global
variable known to the device driver or if you're being really selective,
local to each minor device (ie a component of your minor device control
structure). You can set level with an ioctl, adb or kmem - I prefer the first.

Similarly, you can add another ioctl which either dumps a load of tables there
and then inside the kernel, or else returns some interesting structures to a
debugging program which does with them as it wishes, (cf some of the ideas
for replacing kmem floating around). Again you could do this sort of thing
with kmem or adb directly, but not all of us have "adb -k" and kmem is too
painful for my liking. 

The advantage of using ioctl is that you can then write arbitrarily complex
C programs which set the debugging level or print out selected information
using ioctl, but no doubt you could do the same using a shell-script, adb
and your favourite combination of awk, sed, grep etc.

These ideas are hardly original but perhaps they will be new to some people.

Robert Stroud,
Computing Laboratory,
University of Newcastle upon Tyne