Linux Device Drivers in Assembly
This document is covered by the GNU Free Documentation License v1.1 Page 109
ging can hardly be considered ’normal’ one would expect to find even fewer defects in one’s kernel code
when relying specifically on testing and debugging techniques.
Those same software engineers have found that a programmer can also discover about 60-70% of the
defects in a program through code reviews and code analysis (the two sums are greater than 100% because
there is considerable overlap between the defects the two mechanisms discover). Although normal testing
and debugging operations are much difficult in kernel code, there is really no additional effort to review ker-
nel code than the effort required to review an application with compariable complexity. Therefore, a thor-
ough code review should be the first tool a software engineer uses when attempting to discover the defects in
a device driver. Unfortunately, my experience suggests that few device driver engineers even think to care-
fully analyze their code in an attempt to locate defects. For example, Rubini and Corbet devote a whole
chapter to Debugging Techniques in Writing Linux Device Drivers, Second Edition, and nowhere do they
mention using a code review to locate defects in a device driver (I will give them the benefit of the doubt and
assume that they assume the reader has already analyzed their code; based on my observations, I will not
make this assumption about all my readers).
This chapter, indeed this text, is a far to short to go into all the details behind a full code analysis and
review process. However, it’s easy to make two simple suggestions that are surprisingly effective in tracking
down defects that would be difficult to find using normal debugging techniques: (1) read your code and con-
vine yourself it’s correct, and (2) have someone else read your code and have them figure out what it’s doing.
The first suggestion may seem somewhat stupid. After all, you’ve written your code, how is reading it
going to prove anything about it? Simple, it’s called the mental block. If you’re like me, your mind often
thinks one thing while your fingers type something else during the coding process. The bad news is that it’s
easy to read what you were thinking rather than what you actually typed when scanning over your code.
Therefore, when personally reviewing your code, it’s important to look at one statement at a time and ask
yourself "Do I really understand exactly what this statement is doing?" Be sure that you understand both the
main intent of the statement and any side effects the statement produces before going on to the next state-
ment. Look at the effects of that statement both locally and globally. When you’ve convinced yourself that
the statement is correct, go on to the next one. This may seem laborious (and it is), but it’s amazing how
many defects you can find in the code by following this procedure. In the long run, this takes far less time to
find many defects than you’ll take using traditional testing and debugging techniques. Best of all, this tech-
nique finds defects in code sections that hardly (if ever) execute as easily as it finds defects in code that exe-
cute all the time (these latter ones are the ones that are most easily found using traditional testing and
debugging techniques).
One problem with reviewing your own code is that you can develop mental blocks and no matter how
many times you read over a section of code, you’re likely to always see what you think you see rather than
what’s actually present in the source. Therefore, once you’ve made a couple of passes over your code, it’s a
good idea to have someone else take a look as well. Since they’re operating from a different frame of refer-
ence, they’ll see problems that you continue to miss. Do keep in mind, however, that you shouldn’t waste
another engineer’s time; it’s important that you review your own code first and eliminate all the "low lying
fruit" before taking up someone else’s time in a review process. Remember, when someone else is reviewing
your code, you’re consuming two man hours for each real hour since two of you are participating in the
review. And you should always participate; never hand the code off to someone else and ask them to get
back to you later. You’ll learn a lot more about your code and the two of you will find far more defects
together. Just be sure the easy stuff is taken care of before you involve someone else.
A good way to do a code review with another engineer is to give them the code (and design documenta-
tion!) ahead of time so they can read through the code and learn how it operates. Then have them explain
how they believe it operates to you. This is actually the best way to do the reviews. It’s amazing how many
misconceptions they’ll have about the code and, although their misconceptions may be nothing more than
misconceptions, this feedback will help you document your code better. On the other hand, the things that
they just don’t understand in your code could truly be due to defects in your code. This is the most powerful
form of code review you can do involving other engineers; unfortunately, those other engineers often have
their own projects and don’t "own" your code; therefore, they’re unlikely to invest the time that’s necessary
to understand the code to the level needed to pull this type of review off really well. This type of review
works best when your manager or a project lead is the one who must understand your code (so they can han-
dle project scheduling better) or if you’ve got someone who is going to take over your code when you’re