Linux Kernel Development (2nd Edition)

Building Embedded Linux Systems

Understanding the Linux Kernel

The Linux TCP/IP Stack: Networking for Embedded Systems (Networking Series) (Networking Series)

Embedded Linux: Hardware, Software, and Interfacing

Linux

Linux Device Drivers, 3rd Edition

Format: Paperback
Author: Jonathan Corbet
ReleaseDate: 08 February, 2005
Publisher: O'Reilly Media
Rating:

Don't even read the free online version
I NEVER bothered writting reviews. This book was so badly written that I just couldn't help writing my first review on Amazon.

While I fully respect the authors' decision in providing the book online under the Creative Commons license, and while I do not doubt the sincerity of their intentions, the book is a total f*ck up. And f*ck up is an understatement.

The book:
1) Is unorganized :-

I felt I was being bombarded by information from all directions. One moment I was getting ready to test a simple "hello world" module, and the other I'm suddenly faced with a some strange esoteric block diagram showing "how function calls and function pointers are used in a module to add new functionality to a running kernel. " with strange function names that were not mentioned and do not get mentioned for the rest of the chapter. How the hell did I get here? It just pisses you off and breaks your thought process and leaves you clueless and frustrated.

2) Is upside-down:-

I read chapter 3 (Char drivers) and I compare it to real device drivers and some things just don't match. The book seems very theoretical because the "real" device drivers call some other functions that are not mentioned at all. After digging in the kernel source files and googling the internet I realize that in the "real world" there is a whole driver-model and generic objects and what not. Reading the source code documentation and some online material I actually understand how the "real" drivers work. I still don't understand the stuff in the book. I start wondering whether there is any mention of the driver-model and I find it in chapter 14 !!!!!!! The driver model seems, in my opinion, the first step to understanding how "real" drivers work and I find it after 14 chapters of utter nonsensce!! Not only that, the authors decide that "many driver authors can ignore the device model entirely" and "The complexity of the device model makes it hard to understand by starting with a high-level view". . . surpisingly it was easier to understand from online sources and the source code documentation than trying to read chapter 2 in the book!

3) Is sadistic:-

One thing I really hated was the carrot-and-stick approach the authors chose. First they give you a small tiny taste of a topic which finally seems relevant and just when you feel you're about to reach somewhere, they do a complete u-turn and throw all kinds of irrelevant off-the-topic rubish that leaves you sorry you were so shamefull as to expect any better. You end up confused, annoyed, and duped. Like in chapter 2 when they presented the code for the "hello world" module. OK fine. Seems easy enough. You naturally assume that this is an invitation to write the same code yourself. HAHA WROONG! The book suddenly does a "make hello. c" without showing you the content of the makefile. It leaves you out to dry with your uncompilable-"hello. c" and goes on describing IN DETAIL seemingly random stuff. You are left wondering whether the makefile must have been something too obvious to bother noting down and you start wondering whether to try to create a simple makefile or continue reading the chapter "as-is". I chose the former. HAHAHA WROONG AGAAIIN! I ended up compiling my whole kernel source tree because of something they decide to mention only 7 sections later. (At least they mentioned it?!)

In summary. . I'd suggest you buy the book. . and (as ". /Documentation/ManagementStyle" for another book says): "NOT read it. Burn it, it's a great symbolic gesture".

I don't think anyone could have done a better job at making a worse technical book. If you come across any online material that "recommends" this book, *QUICKLY* discard that material too . . without thinking.

This is a -5 stars book. It has affected me personally.

Specialised skills
]

Device drivers will always be a small speciality in any operating system. [A review of the 3RD EDITION, 2005. Linux is no exception. While it grows strongly, most programmers using it simply can ignore issues of hooking up to various hardware items. Someone has already worked those out. Well, here you are that someone and this book addresses many of your needs.

The coding is in C. No fancy object oriented stuff for you. Many higher level OO programmers are simply unaware of the extra overhead it takes. But you need to maximise performance, so it is C for you. Plus, to understand much of the book, it really helps to have written some assembly code, because it makes it easier to understand many low level operations discussed.

Prior acquaintance with the overall design of a linux memory manager and interrupt handlers is also good. The book explains well individual issues as they arise. But having a clear, top-down understanding of the linux kernel may give you more context to understand the chapters.

great book for the right person
It was very helpfull, but could improve. I used this book to write a device driver for my computer engineering senior project. 2nd edition covers almost everything you'll need for 2. 4 kernel drivers. Organization is like a text book that includes reference material, but attempts to be a tutorial. Hopefully the 3rd edition will be better organized. I noticed lots of negative reviews on Amazon, but after reading some chapters on safari (the oreilly free book site) I decided to purchase it any ways. If you buy this book and don't have a solid background in operating systems, computer architecture, and microprocessor interfacing you probably won't have an easy time understanding several key topics well enough to write a working driver. This will probably make you mad enough to write another bad review.