Linux Kernel Development 3rd Ed 53
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.
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). | 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. |
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.
Robert Love (Score:1)
Where is he now? Doesn't seem to be an active kernel developer since the 1rt edition.
Re: (Score:3, Informative)
Re: (Score:2)
Of course that's what the article says. But I have not seen him on LKML for a long while. In fact I just did some googling, and his name does not turn up much, and for the recent postings on LKML that mentioned him, they were all about this book!
Re: (Score:3, Insightful)
Re: (Score:2)
Some have claimed that open source developers go into Google and disappear. This is correct. I can confirm it from firsthand experience.
Anonymous Coward (Score:3, Funny)
Another book about developing a skillset I wish I had. I hate being web developer, I get no respect.
Re:Anonymous Coward (Score:5, Funny)
If only there were a book to help you build that skillset.
Oh well!
To Earn Respect Accumulate Knowledge (Score:5, Interesting)
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.
Re: (Score:2)
O'Reilly Book Has More Implementation, Less Theory (Score:4, Informative)
It would have been nice if your review had compared other books on the same topic [oreilly.com] so I could know which is best to get.
I think you want to reference the latest edition of that book [amazon.com] 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.
Re: (Score:1)
This is an even better point than many readers of that comment may realize. C is an excellent language to learn if you already know any programming language and you want to expand your horizons. C is a strong influence on the syntax of any language which uses braces to delineate blocks. It is low-level enough to expose all of the nasty resource management and concurrency problems that are normally hidd
Re: (Score:2)
> It is impossible to over-recommend learning C if you're interested in programming at all.
But please, for the love of god, avoid developing your applications with C.
Re: (Score:2)
Part of the efficiency of C is that it is closer to the "bare metal" than high level languages like Java and C#. If you don't have a proper understanding of how C works then it will totally bite you in the ass. Things like garbage collection are a nightmare when improperly implemented in a C program, while it's automatically handled in higher level languages.
Many higher level language compilers can produce fairly efficient code and can be aware of intricate architecture details that the programmer may not k
Re: (Score:2)
Uh, in the C world we call it "memory management", not "garbage collection". (And in the C++ world we call it "resource management", since we have predictable destruction.)
I can accept a lot of inefficiency (like Python'
Re: (Score:1)
Yeah but who gets rich. (Score:2, Interesting)
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.
Re: (Score:1, Insightful)
Respect from other developers doesn't buy jets and super models.
...and supermodels and jets don't buy respect from your peers.
Re: (Score:1)
...and supermodels and jets don't buy respect from your peers.
What follows sums up anything I could possible post. After receiving a scathing review of one of his performances ....
"I cried all the way to the bank!"
- Liberace
Re: (Score:2)
So what does that prove other than he was a rich talentless hack?
Lots of people get rich with pointless shit, hell they give people millions to play handegg or baseball. Kid's games, and they get millions to play it.
Re: (Score:3, Insightful)
Respect from other developers doesn't buy jets and super models.
...and supermodels and jets don't buy respect from your peers.
With jets and super models, who cares?
Re: (Score:1)
Contrary to what you may think, almost no one becomes a developer to "get-rich-quick"... but if that is your only concern, your average kernel developer [indeed.com] gets paid a little better than your average web developer [indeed.com]. My advice... don't go into either with the expectation of becoming a billionaire :-p They generally pay well, but the rich and famous developers are by far the exception, not the rule.
On the other hand, if you've got the NextBigIdea(tm), then by all means feel free to prove me wrong! I know I wou
Re: (Score:1)
Making $100k/year != getting rich, these days.
While that's certainly no salary to complain about in most areas of the US, it is considered upper middle class [wikipedia.org], not rich.
How did this talk about rich developers get started anyway? It's an exceedingly rare occurrence.
Re: (Score:1)
Just do it (Score:2)
AAARGH!! (Score:2)
Forgot to hit "plain old text". WHY is HTML the default? i'm not designing a frickin web page here!!!
It makes the driveby attacks easier (Score:2)
I mean really, you gotta give those Russians a break you know. They have the Chinese to compete with!
Re: (Score:2, Informative)
There is a preference for it, you can set your own default.
Re:Just do it (Score:4, Informative)
"Unless you're writing disc drivers where you need to understand stepper motors (...)"
FYI most device drivers are pretty straightforward and simply require the developer to follow published interface specifications. ATA/ATAPI specifications, for example, have you perform fun operations like seek(long block) and read(long block_start, long block_count), etc. (paraphrasing) where you the application developer don't require any specialized knowledge of the "stepper motors", spindle speed, etc. - you issue the commands, and out comes a response - that's the whole point of having intelligent circuitry and firmware on the disk device. I spent some time in an ATA/ATAPI driver BIOS development prison camp in the late 90's, so have a little experience with that.
Re: (Score:2)
mod parent up.
Clearly this guy has done more kernel hacking than I have (I was just fiddling about with a credit card reader). BUT.. to reiterate my previous post.. there's nothing 733+ about kernel hacking.. it's just code and it makes just as much sense as anything else you wrote. Tangent has been redirected :-)
"To keep this review relatively concise..." (Score:5, Funny)
"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 :-)
Well, It's Either That or 'tl;dr' (Score:2)
"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 [slashdot.org] like these [slashdot.org]? 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.
Re: (Score:2)
To be honest, a book review isn't the same as a book summary. People who buy a book like this generally know what's going to be covered. The real question is quality of coverage.
Maybe picking one or two areas that are of interest to you and discussing how Love's coverage of them gave you deeper understanding might have been the way to go, not to mention less typing for you.
Re: (Score:2)
Whoa! I was just teasing!! I actually thought you wrote a very nice review. I read the whole thing, and I even thought, "that sounds like a really cool book to get if I ever do any more kernel hacking."
Good job. And thanks for the other insightful posts that you often make. I think you're one of the best contributors to slashdot.
Re: (Score:2)
I read all of your review, and I enjoyed it. Now I want to get a copy of the book. Thank you.
It's about time! (Score:1)
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!
Ordered... (Score:1)
Cheers,
Non-x86? (Score:3, Interesting)
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?
Answers (Score:4, Interesting)
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.
Re: (Score:3, Insightful)
It should also be pointed out there is a separate line of books from multiple vendors covering this topic specifically.
At least when discussing developing linux kernel drivers.
Still, no one book is going to be super helpful on developing for a target platform unless you need insight into using the kernel to access these devices. For a device such as an mpeg decoder there are multiple points where it is simply understanding the right ioctals to pass to initialize the hardware. Then it is a matter of understa
Re: (Score:2)
What type of embedded device are we talking about and what type of on chip function.
Are we talking about super all in one chipsets which have the majority of the function stored in the chip. Not many of these solutions actually run linux because they are not general purpose platforms. Now, if we are simply discussing onboard devices (notice the distinction in the language) such as a built mpeg decoding chip or some such device then it's still on the bus. It's just yet another memory address and interval tim
Publishers' web page (Score:2)
More than just Amazon (Score:1)
Powell's [powells.com]
Indiebound [indiebound.org]
Barnes & Noble [barnesandnoble.com]