|
 |
| Fri, Sep 05th | home | browse | articles | contact | chat | submit | faq | newsletter | about | stats | scoop | 15:56 UTC |
|
|
login « register « recover password « |
|
| [Article] | add comment | [Article] |
|
|
|
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. Copyright notice: All reader-contributed material on freshmeat.net is the property and responsibility of its author; for reprint rights, please contact the author directly.
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. Author's bio: Leon Dague was a $5.00/hour counterman in a retail butcher shop prior to going to Coppin State (for one semester) and then UMBC, in his mid 30s. In addition to earning his Bachelor of Science in Computer Engineering, he has worked his way from student clerical assistant in health care research to associate staff of the College of Engineering. His wife Gloria and his friends at Lovely Lane United Methodist Church are managing to keep him out of trouble at the moment. T-Shirts and Fame! We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about. [Comments are disabled]
[»]
Nice review but... I hate maths --
[»]
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.
[»]
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.. --
[»]
Judicious review, but still a difficult book Leon,
--
[»]
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. --
[»]
Nice intro ;-) Hello Leon!
[»]
Re: Nice intro ;-) Hello Tobias!
--
|
|
