Book review: Linux Kernel Development, third edition
One has to dig a little bit to figure out which kernel version is covered
by the third edition; according to the preface, the target is 2.6.34.
Robert, ever the optimist, suggests that it will be good for a long time:
"As the Linux kernel matures, there is a greater chance of a snapshot
of the kernel remaining representative long into the future.
"  Time
will tell.
The third edition has been extensively updated, but it retains the same
structure as its predecessors.  The preface talks of "all-new" chapters,
but the number of chapters remains the same.  The scheduler discussion has
been updated to reflect the merging of the completely fair scheduler.  Other
relatively recent kernel changes (mutexes, for example) have been added,
and there are changes throughout to reflect what has happened over the last
24 kernel releases.
There is a new chapter on kernel data structures; it contains
the linked list discussion previously found in Appendix A, along with
coverage of FIFOs, red-black trees, and the idr subsystem.  The low-level
device model chapter has been combined with the chapter on loadable
modules, for some reason, but the discussion is not much changed.  The
appendix on the random number generator is gone.
All told, the coverage of the core kernel is well written and clear, in an approachable style. Linux Kernel Development is, at this time, probably the best reference available for developers wanting to learn how the kernel works and how the major pieces fit together. Your editor is glad to have a copy on hand.
With that understanding in place, this, too, must be said: the update to the third edition appears to have been done in a hurry. As a result, the book contains a number of errors and inconsistencies, and it fails to cover no end of interesting things which have happened in the kernel over the last five years while retaining text which was obsolete even in previous editions. Robert has not been hugely present in the kernel development community in the last few years (he got a job at a company with a reputation for removing developers from the community) and, unfortunately, it shows.
For example, this book (which covers 2.6.34) includes a section on the
anticipatory I/O scheduler - which was removed in 2.6.33.  There is still
talk of the "Linus" scheduler - which (as is noted in the book) was a 2.4
feature.  The mutual exclusion chapter discusses semaphores - which have
been deprecated for mutual exclusion purposes - with the section on mutexes
seemingly bolted on afterward.  
(The book also says elsewhere that we cannot kill a process in an
uninterruptible sleep because it "may hold a semaphore
")
There is a lengthy discussion of the old
"bottom half" mechanism which is long gone; the removed-in-2.5 task queue
mechanism also merits a section of its own.  The unlamented
ksymoops tool, we are told, "probably came with your
distribution
". 
Some things are simply wrong. We're told that do_exit() calls del_timer_sync(), but that last happened in 2.6.15. The workqueue discussion appears to be stuck in a 2.6.10 time warp; changes which were merged for 2.6.20 are not reflected here. Kernel stack size is said to be 16K on 64-bit architectures because they usually have 8K pages. The version of struct file shown on page 279 never existed; it includes f_ep_lock which was renamed (by your editor) to f_lock in 2.6.30. The "process address space" chapter says, several times, that all Linux systems have three-level page tables, despite the fact that the fourth level was added for 2.6.11. The device model chapter no longer mentions struct subsystem, but it still appears in the associated diagram.
And many things which should be discussed in a contemporary book aren't. Developers working on the kernel now should probably be familiar with control groups, contemporary debugging tools (kmemleak, lockdep, the fault injection framework, ...), debugfs, ftrace, git, high-resolution timers, huge pages, linux-next, multiple slab allocators, namespaces, perf, power management and quality of service, read-copy-update, readahead, reverse mapping in the VM subsystem, scheduler domains, splice(), TASK_KILLABLE, threaded interrupt handlers, virtualization, and so on. No book on the kernel can hope to be complete and still be something that a person of ordinary strength can physically lift, but these topics are all important enough that, one would assume, at least some of them would merit coverage, but none are mentioned in the third edition.
Keeping up with all that is happening in the kernel is hard - your editor hopes that readers will trust him to understand this. So it is not surprising that some mistakes would slip through when a book is fast-forwarded from 2.6.10 to 2.6.34. But the amount of old stuff that leaked through, combined with the things which should have been mentioned but weren't, seems a bit high; some of them should, at least, have been caught in technical review. As a result, the third edition of Linux Kernel Development is not as good as it could have been.
These grumbles notwithstanding, your editor will restate what was said
above: this book remains 
the best overview of contemporary kernel development available today.
Robert is a talented and engaging writer who is able to cover complex
topics in a readily understandable manner.  The third edition merits a
place on the "L1 bookshelf" (the one which can be reached without getting
out of the chair); developers who are working with the kernel will
probably want a copy.
| Index entries for this article | |
|---|---|
| Kernel | Books | 
      Posted Dec 15, 2010 18:45 UTC (Wed)
                               by karim (subscriber, #114)
                              [Link] (4 responses)
       
In the mean time, Robert's book has been added to my Wishlist. 
     
    
      Posted Dec 15, 2010 18:46 UTC (Wed)
                               by corbet (editor, #1)
                              [Link] (2 responses)
       
     
    
      Posted Dec 15, 2010 18:51 UTC (Wed)
                               by karim (subscriber, #114)
                              [Link] 
       
     
      Posted Dec 15, 2010 19:30 UTC (Wed)
                               by shapr (subscriber, #9077)
                              [Link] 
       
 
     
      Posted Dec 15, 2010 18:56 UTC (Wed)
                               by flewellyn (subscriber, #5047)
                              [Link] 
       
I, uh, think you have been.  For some time now. 
     
      Posted Dec 15, 2010 19:19 UTC (Wed)
                               by pranith (subscriber, #53092)
                              [Link] (2 responses)
       
That was one good book with lots of details. 
     
    
      Posted Dec 16, 2010 9:07 UTC (Thu)
                               by mces (subscriber, #27668)
                              [Link] (1 responses)
       
I could not agree more with our editor: 
"Keeping up with all that is happening in the kernel is hard - your editor hopes that readers will trust him to understand this."  
The Linux kernel is a fast moving target. A new edition of UTLK will likely cost a couple of years of hard, full-time work. Furthermore, the new book edition will likely become obsolete in a couple of years since its appearance. 
Perhaps we should look for alternative, more efficient ways to write kernel documentation.  
Marco Cesati 
 
     
    
      Posted Dec 19, 2010 2:47 UTC (Sun)
                               by pranith (subscriber, #53092)
                              [Link] 
       
     
      Posted Dec 15, 2010 21:01 UTC (Wed)
                               by neilbrown (subscriber, #359)
                              [Link] (2 responses)
       
This reads as though ksymoops is no longer needed ... yet I know of nothing better for translating the "Code: XX XX XX XX <YY> XX" line that comes out with an Oops message. 
     
    
      Posted Dec 16, 2010 19:24 UTC (Thu)
                               by sbohrer (guest, #61058)
                              [Link] (1 responses)
       
     
    
      Posted Dec 16, 2010 22:22 UTC (Thu)
                               by neilbrown (subscriber, #359)
                              [Link] 
       
I could even hack that to process a command-line-arg which is sometimes easier to provide than stdin. 
Thanks! 
 
     
      Posted Dec 15, 2010 21:02 UTC (Wed)
                               by ClarkMills (guest, #11490)
                              [Link] (2 responses)
       
     
    
      Posted Dec 27, 2010 19:10 UTC (Mon)
                               by jd (guest, #26381)
                              [Link] (1 responses)
       
Also, I'd suggest moving from the monolithic book concept to a framework where each chapter is on a rail of some kind and can be slid out and replaced. The book will then never be "out-of-date" and the upgrades can all be sold in such a manner that it makes the publisher just that little bit richer. 
 
     
    
      Posted Dec 29, 2010 14:25 UTC (Wed)
                               by eliezert (subscriber, #35757)
                              [Link] 
       
     
      Posted Dec 16, 2010 1:27 UTC (Thu)
                               by dougg (guest, #1894)
                              [Link] (3 responses)
       
     
    
      Posted Dec 16, 2010 2:03 UTC (Thu)
                               by corbet (editor, #1)
                              [Link] (2 responses)
       
     
    
      Posted Dec 16, 2010 18:11 UTC (Thu)
                               by Webexcess (guest, #197)
                              [Link] (1 responses)
       
     
    
      Posted Dec 16, 2010 18:15 UTC (Thu)
                               by corbet (editor, #1)
                              [Link] 
       
Yes, there are easy ways to get up a mailing address in another state and get back into things, but it doesn't seem worth the trouble.
 
Thanks for the thought, though!
      
           
     
      Posted Dec 16, 2010 2:23 UTC (Thu)
                               by aschwinm (guest, #33817)
                              [Link] 
       
It's probably one of the last physical technical books I bought, bringing over 10 books to the customer site is too much (I leave them in the car but still). This book is one of the three books I have on my desk though. 
You can find a review of this book by Klaas van Gend at the Meld web site: http://meld.org/discussion/education/book-review-linux-ke... Meld is an embedded Linux community. 
Aschwin Marsman 
     
      Posted Dec 16, 2010 18:02 UTC (Thu)
                               by Lovechild (guest, #3592)
                              [Link] 
       
     
      Posted Dec 23, 2010 4:14 UTC (Thu)
                               by dong.chen.xn (guest, #71987)
                              [Link] (3 responses)
       
     
    
      Posted Jan 4, 2011 13:40 UTC (Tue)
                               by fabbo (guest, #63822)
                              [Link] (1 responses)
       
     
    
      Posted Jan 4, 2011 16:46 UTC (Tue)
                               by nye (subscriber, #51576)
                              [Link] 
       
     
      Posted Jan 5, 2011 22:19 UTC (Wed)
                               by klossner (subscriber, #30046)
                              [Link] 
       
     
    Book review: Linux Kernel Development, third edition
      
      Let's just say you'll have plenty of time to enjoy Robert's book while you're waiting...
      
          Book review: Linux Kernel Development, third edition
      Book review: Linux Kernel Development, third edition
      
Book review: Linux Kernel Development, third edition
      
Thus I'd like to see a higher definition version of the "and so on" part of that list.
Book review: Linux Kernel Development, third edition
      
Book review: Linux Kernel Development, third edition
      
Book review: Linux Kernel Development, third edition
      
Book review: Linux Kernel Development, third edition
      
Book review: Linux Kernel Development, third edition
      
Book review: Linux Kernel Development, third edition
      
Book review: Linux Kernel Development, third edition
      
Suggestion: Jon to proofread?
      
Suggestion: Jon to proofread?
      
Suggestion: Jon to proofread?
      
I guess some sort of credit system would need to be put in place to motivate people to work on this.
Maybe we can have our own peer reviewed scientific Linux documentation Journal, so that people from the academia could do Linux documentation and have it count as a publication.
Book review: Linux Kernel Development, third edition
      
      We have copies of the book; reviewing it is on our list of things to do.  Needless to say, it's not a small task...
      
          The Linux Programming Interface
      Affiliate link?
      
      No affiliate link, alas.  The state legislature here in Colorado engaged in some high-handed tactics in an attempt to collect sales taxes from Amazon.  Amazon brought out its own high-handed tactics - and abruptly closed every affiliate account in the state.  I can only say I'm glad we didn't depend on that income stream for anything.
Affiliate link?
      Book review: Linux Kernel Development, third edition
      
Book review: Linux Kernel Development, third edition
      
Book review: Linux Kernel Development, third edition
      
Book review: Linux Kernel Development, third edition
      
Book review: Linux Kernel Development, third edition
      
Book review: Linux Kernel Development, third edition
      
           