Articles / Linux Device Drivers

Linux Device Drivers

I'm afraid to read Linux Device Drivers. It's not that I didn't do a good first reading; of course I did. It's not that I'm not prepared. I read K and R (The C Programming Language), lovingly doing every exercise, around 1986, and have used C on-and-off since then. These days, I read man pages and info documentation on a daily basis, and am thoroughly comfortable with compiling and installing kernels. You will need these skills to read Linux Device Drivers.

It's not that the book itself is frightening. The preface sets a friendly, conversational tone that is continued throughout. It is described as "a starting point for people who want to become kernel hackers but don't know where to start". That identifies me exactly, and for me, this book is clearly "where to start".

It's not that I can't read hard material. Before transferring into the computer engineering program at UMBC, I took all the math my community college offered, and I took it by independent study. One professor said I was the best math student he had ever seen; an encouragement I earned not by being brilliant, certainly, but by meticulously logging the time I spent at the desk with pencil in hand and eyes on the work: 6 to 12 hours a day.

The problem with Linux Device Drivers is that reading it will force lifestyle changes. It's been fun (and fairly comfortable) being a Linux "consumer". I can convert my PCs from Red Hat to woody while goofing off with the wife and keeping my weight up with apple pies and homemade milkshakes. Getting my Linksys wireless card to work was just a matter of downloading a few files and following the instructions, because "producers" had done the real work. Merely being a competent Linux user has required neither staring at source code nor the level of discipline I practiced as a math student.

But a commitment to device driver development is not something a family man can do in his "spare time" (because no one has any), nor while in a food coma from large meals, nor while chatting on mailing lists or gazing at pretty pictures. It really is about facing the source code.

After a few introductory paragraphs, Chapter 1 ("An Introduction to Device Drivers") begins with a discussion of the mechanism vs. policy distinction. This discussion is well placed; the authors successfully set a tone, reinforced throughout the book, that will help new device driver developers focus on business and avoid wasting countless hours on creating unnecessary and frustrating complexity. Also, this kind of insight makes Linux Device Drivers more than merely a nuts-and-bolts HOWTO; my feeling is that this confident discussion of "what to do, what not to do, and why" could have been written only by people with maturity and experience.

The "Security Issues" discussion has the unfortunate feeling of something that was dropped in as an awkward, token hand wave toward the subject. Is it really useful to discuss security issues with readers who have yet to learn the basic structure of modules and device drivers? I suggest that relevant questions at this point might be: "As I do the exercises in this book, is there a chance that I will (e.g.) destroy a partition? Or, if my computer is connected to a network, could I conceivably make my computer vulnerable to attack, or disrupt the network? If so, what precautions should I take?"

Chapters 2 and 3 ("Building and Running Modules" and "Char Drivers") required that I read them as a unit. Chapter 2 raises questions that are answered by Chapter 3, and Chapter 3 required a re-reading of Chapter 2. The object of this two-chapter unit is stated in the introduction to Chapter 3: "To write a complete char device driver". (And that it does.)

I show my age by admitting that I expected the book to contain full source code that I could type in if I chose. (I remember typing in assembly code from Charles Petzold's articles in PC Magazine.) But no, readers must obtain the source code provided at What I did do, even on first reading, was go over every line in scull/main.c and scull/Makefile and ensure that either (a) I understood that line or (b) a detailed question statement was recorded, along with any partial answers or guesses I might have.

That's not a trivial point. My strong feeling is that this is like a good calculus textbook; all the presented material has a purpose. A lesson I took from mathematics is that if I have a question on any significant point in the material, I need to resolve it as well as possible because any questions I ignore will certainly rise up and bite me in the ass later. Looking at it more positively: Questions are important; questions are how I learn. YMMV.

Writing device drivers looks a lot like work, and Chapter 4 ("Debugging Techniques") makes no attempt to convince us otherwise. It begins with a thorough (and thoroughly useful) introduction to printk. One footnote suggests that "syslog.conf(5) [is] a manual page worth reading", and, in fact, I found myself spending hours in several man pages, including klogd(8) and ksymoops(8).

I'll take a moment here to remember my operating systems course at UMBC, during which the instructor commented that the Unix man pages are "not worth two cents". While growing up in Ohio, I heard the saying "Those who can't take the heat should stay out of the kitchen". I hope that as a result of books like Linux Device Drivers, the number of competent cooks will increase (i.e., we'll have teachers who can read the existing documentation and source code, and perhaps even contribute to the growing body of quality writing).

Chapter 4 also contains a brief, but satisfying, introduction to using the /proc filesystem. This is welcome to someone who has been using it while knowing very little of its mechanism or motivation. As Chapter 4 progresses, I get a good feeling that the authors have indeed used the techniques they are teaching. The last few pages of the chapter contain the observation that "Linus does not believe in interactive debuggers". I take that as an indication that the "advanced debugging features" are not what I need at this point; therefore, I will ignore them.

Chapter 5 ("Enhanced Char Driver Operations") completes the basic char driver education with discussions of ioctl, capabilities, blocking I/O (wait queues), non-blocking I/O (polling), asynchronous notification, and seeking a device. There are introductory paragraphs on race conditions.

The authors consider Chapters 1 through 10 to be the "first part" of the book, but for the beginning reader (well, maybe just me), I consider Chapters 2 through 5 as my "first part". I feel that the material in these four chapters (except for the few pages on interactive debuggers in Chapter 4) is so fundamental that, before proceeding further, I should be able to reproduce their essential contents from memory. Since this material is illustrated in 1300 lines of code (scull/main.c and scull/pipe.c), this does not seem to be too much to ask.

A first reading of Chapters 6 through 10 gives the sense that they are indeed at about the same level of difficulty as Chapter 5 -- detailed by necessity, but accessible to the persistent and serious student. In fact, in my review notes, I have a comment which says that by the end of Chapter 6, I began to feel "This is way too understandable".

A personal milestone occurred when I reached the "Owl" note (concerning use of C's "unsigned" type) in the "Using I/O Ports" section of Chapter 8 ("Hardware Management"). At that point, I found that any remaining thoughts of "Are these guys for real? Do they know what they are teaching?" were being put to rest. They were replaced by a sense of being in a training situation similar to Army tech school (Fort Gordon, Georgia, 1979). I had a sudden insight into what this book really is, and why people who support Linux might make this kind of literature freely available on the Internet. This is a training manual for device driver developers and potential future kernel developers.

That's a good place to stop. With all due respect, I need to be reorganizing (resurrecting) my life to read this book, a lot more than I need to keep screwing around with this review. A glance through the later chapters on block devices, network drivers, and buses convinces me (if there were any remaining doubt) that this book is about writing real code to control real hardware.

If I can rebuild the character needed to read this disturbingly understandable book, the final chapter (16), "Physical Layout of the Kernel Source", looks like an invitation to just keep walking and go right off the deep end.

Recent comments

18 Jul 2002 05:03 Avatar Jorion

Nice review but...
I hate maths

05 May 2002 14:14 Avatar ruok

Great book, but..
It sure would have been nice to see at least one hardware example. I know they make several references to reading the PCI or ISA bus specs, but still.. It would have been nice to go "oh ok, thats how it works" for the non-hardware engineer types.

24 Apr 2002 05:54 Avatar Aredhead

Great review.
Thank you Leon, for enlightning me. The "Linux Device Drivers 2.ed." was on my list, as the next O'reilly book to buy, now I know I just need it..

22 Apr 2002 09:25 Avatar ldague

Re: Judicious review, but still a difficult book
Thanks for this positive comment on my review.

Getting a particular hardware item to work with
a particular linux box (assuming that the hardware item is "linux-compatible", i.e. that someone has done the work to support it) is a topic in linux administration. Perhaps it should be made clear that Linux Device Drivers is NOT a book on linux administration.

My review is written from the viewpoint of an independent student. As noted, it is to such a reader's advantage to be comfortable in linux administration, including the compiling and installation of kernels. Such a reader will know
exactly where the kernel source tree is, because s/he put it there :-)

The book is not perfect. But, for someone who has been looking for an accessible entry point to the kernel, it doesn't have to be perfect. It just
has to work.

20 Apr 2002 19:28 Avatar miahfost

Judicious review, but still a difficult book

Your review was careful and exacting, you carefully went through the chapters and
described their contents accurately. But I fear that the book is really less the sum of
its parts. It is never stated clearly what a device driver is. I know it says it is a
set of routines, but by any definition that is incredibly vague.

When one wants to get a printer to work with Linux, and one is not an experienced kernel
hacker, a set of files and examples of those files would go a long way towards getting
one's printer printing. So where is it in this book? That list of files which says;

You need:
1. A module - (inserted into the kernel)
2. A char device - (/dev/print for example)
3. A set of files in C for printer functions
4. Major and minor numbers

Plus, much of the information in the book seems outdated, like where a great deal of the
source code is located. If you use RedHat there is no /usr/src/linux directory, so it is
very hard to find the source files and the necessary .h files to copy from.

I know programming is hard, and I know Linux/UNIX is complex, especially when writing
low-level device drivers, but this book merely muddies the water I am afraid. It needs
greater clarity and better organization.



Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.


Project Spotlight


An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.