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 http://www.oreilly.com/catalog/linuxdrive2/. 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.