Slashdot Mirror
Linux Kernel Development 3rd Ed
eldavojohn writes "Linux Kernel Development Third Edition by Robert Love is the perfect book for the beginning or intermediate Linux kernel hacker. It provided me an excellent bridge between the high level introduction I had in college (from Operating Systems Concepts) and the actual kernel code. The best part about this book is that the chapters are — like the kernel — modular, and allow the reader to dig down in a particular part if they have a specific interest. This, in conjunction with Love's indications of which files and code snippets contain the logic, gave me confidence to clone the kernel, make tiny adjustments, compile and run. At four hundred pages, the book is a long read, but for kernel newbies like me it's a better alternative to jumping into the millions of lines of code. While you might find this information in pieces floating around online, this book balances clarity with brevity in an exceptional manner. It should also be noted that this book defaults to the x86 architecture when explaining architecture-sensitive parts of the kernel (with 64-bit differences occasionally outlined)." Keep reading for the rest of eldavojohn's review.
Linux Kernel Development Third Edition
author
Robert Love
pages
480
publisher
Addison-Wesley Professional
rating
10
reviewer
eldavojohn
ISBN
978-0-672-32946-3
summary
A thorough guide to the design and implementation of the 2.6 Linux kernel tailored for developers.
If you're unfamiliar with Robert Love, let's just say he's been active in contributing to the Linux kernel for fifteen years and he's currently at Google and was part of the Android team. This is his third edition of Linux Kernel Development, and it's tailored to the 2.6 kernel. The first chapter of this book gives you a very brief history of Linux along with an explanation that a major upgrade has been postponed and 2.6 is a very stable and capable version to use. I'd imagine many companies today (like my own) live and die by the capabilities of 2.6 hosting a variety of services. The second chapter sets you up with git to clone the code and deploy it locally without hosing your kernel. If you'd like to sample Love's writing style, these two chapters are available for preview online (PDF).
From there on out, Love divides the kernel up and proceeds to ease the reader into each realm that he covers. You won't get full coverage of the kernel but he delivers the most important chunks that he can in 400 pages and makes good on keeping the material in focus. Every chapter seems to follow a pattern of a few pages of generic remedial kernel design talk then a few pages of Linux specific historical approaches to said design followed by the meat and potatoes in 10 to 40 pages depending on how much code is cited. A short paragraph or two tidies up each chapter to segue into the next one. I failed to find any weaknesses in Love's writing. While he struggles to keep the reader engaged and entertained at times, there's simply too much explaining to be done for him to waste pages on wit and banter. If any of that is to be found, it's sprinkled around the intros and outros surrounding some genuinely solid technical writing. To keep this review relatively concise, I'll only fully cover the content in the first half of the book.
Chapters three and four focus on processes and how the kernel manages them. Love glosses over some basic concepts (i.e. the state transition diagram of a process) about process creation but also includes small code snippets ranging from function signatures to iterative algorithms that do the heavy lifting when initializing and maintaining processes and their hierarchical structures. If you've ever wondered exactly what happens during a fork or how zombie processes are managed, it's all answered here in English. The book moves on to Linux's relatively new completely fair scheduler (CFS) and also describes how to switch out schedulers (the older schedulers appear to remain unused in the code if you want to swap them back in). Love concentrates on kernel/sched.c and kernel/sched_fair.c as he explains the code and flags that control waking, sleeping, preemption and context switching. For me this was one of the most interesting parts of the book where the reader gets to see timeslice and 'nice' factors at work in the actual code. The runnable processes are managed in a red-black tree and Love takes care to show how these are cached and used in the code. As I read these chapters, I couldn't help but wonder how companies like Google tailor the Linux kernel to their needs inside their massive server farms — the care to 'waste not' is already so evident in Love's explanations that tweaking through settings and flags or even rewriting seems like a hard route to save cycles.
Chapter five is a brief how-to about system calls in Linux. This chapter details how to create a system call and how to register it, but also gives background on how the kernel handles system calls and explains concisely how Linux handles system calls in regards to security and stability. Most importantly this chapter explains why you should rarely — if ever — resort to system calls (if it's not accepted as part of the kernel, you face future conflicts with the syscall number).
Chapter six was a bit of a surprise to me but outlines in depth four data structures (linked lists, queues, maps and red black trees). If you code only for Linux and you are rolling your own of any of these data structures then this chapter is for you. It's a bit of a flashback for me but important to note so that one does not duplicate these efforts inside the already expansive code in the kernel. Indeed, this topic is an addition to the book that was not present in the second edition.
Chapter seven is a good illustration of Love's ability to ease the reader into the kernel. He starts off giving a high level introduction to hardware interrupts and their superiority to hardware polling. Form there he explains interrupt handlers and finally the top half (handler) versus the bottom half (deferred workload). This four page intro to the chapter helps beginners like myself prepare for the coming sections on writing a hardware interrupt handler, registering it, unregistering it, disabling all or some handlers, explaining /proc/interrupts and checking contexts. This chapter lays the foundation for following chapters and shows the basics of interrupt handlers. Chapter eight, of course, covers exactly what was left unexplained in the prior chapter — the bottom half. And again the chapter eases into it with an explanation detailing bottom halves. Love gives just the right amount of background (a few paragraphs) to help the reader understand why we are about to discuss softirqs (statically defined bottom halves), tasklets (dynamically defined bottom halves built on top of softirqs) and work queues at great length.
Chapters nine and ten begin with topics the reader might already have some familiarity with: race conditions. Nine begins with the standard topic of the kinds of problems race conditions pose and how one can handle them. The reason for this is the advent of symmetrical multiprocessing (SMP) support that has faced increasing demand in modern operating systems. Love covers what questions the reader should be asking themselves when writing code that may be adversely affected by more than one processor. Love warns the reader that this is not something that can be tacked on at the tail end of development; it must be in the developer's mind from the start. This leads nicely into chapter ten which recalls these problems and explains the many different ways they can be addressed inside the Linux kernel. For each of these approaches, Love outlines the C functions that are available with a brief description. Love lists them in increasing complexity and decreasing frequency: atomic operations, spin locks, semaphores, mutex, completion variables, sequential locks and the Big Kernel Lock (BKL). For each of these, Love provides bullets of guidelines on when to use them versus the others. The most useful of the tables int his chapter are those that contain requirement/recommended tables that help prescribe the reader a solution. But Love advises that the simplest mechanism should be employed unless more complexity is demanded. He also advises the reader to try out several options before settling on the best way to enforce synchronization and handle concurrency. Aside from the specific technical details, this chapter was full of useful rules and guidelines to keep in mind.
The rest of the book covers — in equally excellent detail — the topics of: timers and their management, memory management, VFS, address space, I/O, page caching, debugging and portability. Love also gives some short pointers on code style, creating patches and how to join the community in the final chapter. Skimming the ToC from the second edition (also on 2.6) reveals no major changes to topics aside from some reordering and updating of sample code (like the completely fair scheduler). It's clear that Love has set out to provide a comprehensive guide to the Linux kernel and if you are looking to work intimately with the kernel for fun or for profit then this is the definitive book for delving below the surface of Linux.
You can purchase Linux Kernel Development Third Edition from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
From there on out, Love divides the kernel up and proceeds to ease the reader into each realm that he covers. You won't get full coverage of the kernel but he delivers the most important chunks that he can in 400 pages and makes good on keeping the material in focus. Every chapter seems to follow a pattern of a few pages of generic remedial kernel design talk then a few pages of Linux specific historical approaches to said design followed by the meat and potatoes in 10 to 40 pages depending on how much code is cited. A short paragraph or two tidies up each chapter to segue into the next one. I failed to find any weaknesses in Love's writing. While he struggles to keep the reader engaged and entertained at times, there's simply too much explaining to be done for him to waste pages on wit and banter. If any of that is to be found, it's sprinkled around the intros and outros surrounding some genuinely solid technical writing. To keep this review relatively concise, I'll only fully cover the content in the first half of the book.
Chapters three and four focus on processes and how the kernel manages them. Love glosses over some basic concepts (i.e. the state transition diagram of a process) about process creation but also includes small code snippets ranging from function signatures to iterative algorithms that do the heavy lifting when initializing and maintaining processes and their hierarchical structures. If you've ever wondered exactly what happens during a fork or how zombie processes are managed, it's all answered here in English. The book moves on to Linux's relatively new completely fair scheduler (CFS) and also describes how to switch out schedulers (the older schedulers appear to remain unused in the code if you want to swap them back in). Love concentrates on kernel/sched.c and kernel/sched_fair.c as he explains the code and flags that control waking, sleeping, preemption and context switching. For me this was one of the most interesting parts of the book where the reader gets to see timeslice and 'nice' factors at work in the actual code. The runnable processes are managed in a red-black tree and Love takes care to show how these are cached and used in the code. As I read these chapters, I couldn't help but wonder how companies like Google tailor the Linux kernel to their needs inside their massive server farms — the care to 'waste not' is already so evident in Love's explanations that tweaking through settings and flags or even rewriting seems like a hard route to save cycles.
Chapter five is a brief how-to about system calls in Linux. This chapter details how to create a system call and how to register it, but also gives background on how the kernel handles system calls and explains concisely how Linux handles system calls in regards to security and stability. Most importantly this chapter explains why you should rarely — if ever — resort to system calls (if it's not accepted as part of the kernel, you face future conflicts with the syscall number).
Chapter six was a bit of a surprise to me but outlines in depth four data structures (linked lists, queues, maps and red black trees). If you code only for Linux and you are rolling your own of any of these data structures then this chapter is for you. It's a bit of a flashback for me but important to note so that one does not duplicate these efforts inside the already expansive code in the kernel. Indeed, this topic is an addition to the book that was not present in the second edition.
Chapter seven is a good illustration of Love's ability to ease the reader into the kernel. He starts off giving a high level introduction to hardware interrupts and their superiority to hardware polling. Form there he explains interrupt handlers and finally the top half (handler) versus the bottom half (deferred workload). This four page intro to the chapter helps beginners like myself prepare for the coming sections on writing a hardware interrupt handler, registering it, unregistering it, disabling all or some handlers, explaining /proc/interrupts and checking contexts. This chapter lays the foundation for following chapters and shows the basics of interrupt handlers. Chapter eight, of course, covers exactly what was left unexplained in the prior chapter — the bottom half. And again the chapter eases into it with an explanation detailing bottom halves. Love gives just the right amount of background (a few paragraphs) to help the reader understand why we are about to discuss softirqs (statically defined bottom halves), tasklets (dynamically defined bottom halves built on top of softirqs) and work queues at great length.
Chapters nine and ten begin with topics the reader might already have some familiarity with: race conditions. Nine begins with the standard topic of the kinds of problems race conditions pose and how one can handle them. The reason for this is the advent of symmetrical multiprocessing (SMP) support that has faced increasing demand in modern operating systems. Love covers what questions the reader should be asking themselves when writing code that may be adversely affected by more than one processor. Love warns the reader that this is not something that can be tacked on at the tail end of development; it must be in the developer's mind from the start. This leads nicely into chapter ten which recalls these problems and explains the many different ways they can be addressed inside the Linux kernel. For each of these approaches, Love outlines the C functions that are available with a brief description. Love lists them in increasing complexity and decreasing frequency: atomic operations, spin locks, semaphores, mutex, completion variables, sequential locks and the Big Kernel Lock (BKL). For each of these, Love provides bullets of guidelines on when to use them versus the others. The most useful of the tables int his chapter are those that contain requirement/recommended tables that help prescribe the reader a solution. But Love advises that the simplest mechanism should be employed unless more complexity is demanded. He also advises the reader to try out several options before settling on the best way to enforce synchronization and handle concurrency. Aside from the specific technical details, this chapter was full of useful rules and guidelines to keep in mind.
The rest of the book covers — in equally excellent detail — the topics of: timers and their management, memory management, VFS, address space, I/O, page caching, debugging and portability. Love also gives some short pointers on code style, creating patches and how to join the community in the final chapter. Skimming the ToC from the second edition (also on 2.6) reveals no major changes to topics aside from some reordering and updating of sample code (like the completely fair scheduler). It's clear that Love has set out to provide a comprehensive guide to the Linux kernel and if you are looking to work intimately with the kernel for fun or for profit then this is the definitive book for delving below the surface of Linux.
You can purchase Linux Kernel Development Third Edition from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Where is he now? Doesn't seem to be an active kernel developer since the 1rt edition.
Another book about developing a skillset I wish I had. I hate being web developer, I get no respect.
Another book about developing a skillset I wish I had. I hate being web developer, I get no respect.
As the reviewer, I too am a web developer (Java & Ruby). While I might not be using Linux Kernel Development in my profession on a regular basis, there's no reason why you can't hack away at home in your spare time. As I mention in the review, the 2.6 kernel basically keeps my web apps afloat so it's nice to know more about how the kernel operates internally. Am I qualified to release a distribution optimized for web hosting? Definitely not right now but after the chapter on debugging and understanding how the scheduler works, I feel more confident when I SSH into a box to check out what's going on with Mongrel or Tomcat.
Your education doesn't have to end the second you accept your first paycheck. If you don't know C, that's just another thing to learn before starting down this road. I implore you to expand your skill set, who knows what you may find? The great thing about this book was that it's mostly English. So even if you don't know C, you could hobble through the code examples (like Legolas' singing in Lord of the Rings) and stick mostly to Love's English explanation of it.
My work here is dung.
The number of OS billionaires is at zero - no, Bill Gates doesn't count because he bought his first OS and then had others write the OS when he became a big shot business guy.
Respect from other developers doesn't buy jets and super models.
RIP America
July 4, 1776 - September 11, 2001
The kernel has become so complete now, I rarely look at the source for any reason other than interest. I once wrote a couple of mods for the whole "I hacked linux" kudos thing, before realising it's just like programming anything else.. except the crash bit.. that's annoying. That's what qemu/kvm/vmware/virtualbox is for. Unless you're writing disc drivers where you need to understand stepper motors, it's just code.. the same crap you find in all the other stuff you've done, only you get to see the word "oops" occasionally. Therein lies a problem.. there's a lot of money out there for kernel hackers (just ask any mobile phone company), but as a home user, you need a reason, or at least a goal to do it. Someone should release an open-hardware usb stick with an LED on it with a closed source driver. Your goal is to make the LED turn on. And NO, they shouldn't publish how to do it :-D
I wrote my first program at the age of six, and I still can't work out how this website works.
Forgot to hit "plain old text". WHY is HTML the default? i'm not designing a frickin web page here!!!
I wrote my first program at the age of six, and I still can't work out how this website works.
"To keep this review relatively concise, I'll only fully cover the content in the first half of the book."
Yeah, I only read the first half of my assignments before writing the reports, too :-)
I mean really, you gotta give those Russians a break you know. They have the Chinese to compete with!
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
It's about time the kernel got into this 3-D hype. I need to install it on my glasses for this fancy shmancy 3D TV the Best Buy guy told me was wicked awesome!
"To keep this review relatively concise, I'll only fully cover the content in the first half of the book."
Yeah, I only read the first half of my assignments before writing the reports, too :-)
I guess I have to pick between comments like the above and comments like these? Twenty thousand bytes it is next time.
I'd be happy to answer any questions you have about the other subjects he wrote of (timers and their management, memory management, VFS, address space, I/O, page caching, debugging and portability).
Just feels like nobody reads the really long reviews anyway.
My work here is dung.
It would have been nice if your review had compared other books on the same topic so I could know which is best to get.
I think you want to reference the latest edition of that book which is also the Third Edition and also based on the 2.6 kernel. The book you linked is from 2000 and based on 2.3 I believe.
It appears that the O'Reilly book focuses more on the tiny implementation details while Love's book has more theory. The O'Reilly book is more than twice as long as Love's book. The O'Reilly book was also published in November 2005 so I doubt it would have anything on the Completely Fair Scheduler or any advancements since then.
I wish I had more time to give you a better review but the fact is that I'm new to this stuff and this is the only book I've read devoted solely to the Linux Kernel. The Love book is a solid book though (hence the 10/10) and if you're looking for a current Linux guide, it's probably the newest.
My work here is dung.
...Now!
Cheers,
I've been working on a driver for an embedded PPC, and referring to the companion book "Linux Device Drivers 3rd ed", and one of the things that struck me about it was the implicit assumptions that:
1) All the world is an X86
2) All the world's devices are on either PCI, ISA, or USB.
There were no descriptions about non-X86 device, no descriptions about devices NOT on a PCI bus (e.g. embedded devices on-chip peripherals).
Does this book talk about any non-x86 arch issues?
www.eFax.com are spammers
Does this book talk about any non-x86 arch issues?
They are few and far between. On page 176 and 177 when Love is discussing Atomic Integer Operations (Chapter 10, Kernel Synchronization Methods), he mentions the atomic_t structure and Love mentions the SPARC port of Linux and an odd implementation choice to have the lower 8 bits of the atomic_t structure be lock bits. This means that there were only 24 bits available to be used on SPARC machines. Now, I assume this has since been rectified but you generally don't get another architecture mentioned unless there are curiosities that Love wants to mention about code in the asm director of the source tree.
So from there he starts talking about asm/atomic.h and explains to the reader that because atomic integer operations are architecture dependent, you get different support for additional methods that may be unique to an architecture. He treats 64 bit specific things the same way. You don't get as full of an explanation but you do get something when it's interesting and noteworthy.
Now, of course, Chapter 19 on portability covers many architectures but doesn't really dive deep into any of the alternatives. Love remains at a pretty high level and adheres to English explanations of caveats that occur with different architectures. Which is why I think this book would be good for you despite a 32 bit x86 architecture. Even though he might be looking at x86 architecture code, most of the code cited in this book is architecture independent. On top of that, you're getting an English explanation alongside it so that if you were really pressed to look at the PPC equivalent, the English is going to tell you what something does and there will probably be a lot of similarities in what function must be performed.
no descriptions about devices NOT on a PCI bus
As for your second point I don't recall a bias to PCI, ISA or USB devices in chapter 17. In fact, it was more so about the four kernel components (device types, modules, kernel objects and sysfs) the kernel has implemented to support any possible device. The downside is that if you're looking for a detailed guide on the PCI bus, this isn't it. This is more about what code is in the kernel to take care of any device technology with no favoritism given. I just checked the index for any of those three acronyms and must confess that if they were mentioned, little time was given to them. This book is about the kernel code and how the kernel code handles those kinds of things. I think the scope of this book and the length of it is not meant to include something like individual specific bus technologies.
My work here is dung.
Pearson have a page for the book at http://pearsonhighered.com/educator/product/Linux-Kernel-Development/9780672329463.page
Probably because I'm not over Amazon's de-listing debacle, I like to remind everyone that there other bookstores on the Internet.
Powell's
Indiebound
Barnes & Noble
eldavojohn, I think /. should just suck it up and hire you. I'm pretty sure you provide them with all the content that's any good.
Socketpuppet much?