Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux Kernel Development 3rd Ed

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Programming 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).

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.

cancel ×

53 comments

Sorry! There are no comments related to the filter you selected.

Robert Love (0)

microbee (682094) | more than 3 years ago | (#33763448)

Where is he now? Doesn't seem to be an active kernel developer since the 1rt edition.

Re:Robert Love (3, Informative)

slaxative (1867220) | more than 3 years ago | (#33763496)

It says what he's been up to in the article ... "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."

Re:Robert Love (1)

microbee (682094) | more than 3 years ago | (#33763554)

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:Robert Love (3, Insightful)

Anonymous Coward | more than 3 years ago | (#33763564)

Looks like he's been busy writing this book :P

Re:Robert Love (0)

Anonymous Coward | more than 3 years ago | (#33767134)

One way to look at it is that working on the book took his time, another way would be that he has lost it and is now trying to salvage his obsolete x86 kernel from a few years ago knowledge to pay for his mental health expenses.

The only general purpose 32-bit architecture I want to see on a book published in 2010 is ARMel. amd64, ppc, loongson, ... - anything else one could imagine being on a computer now, is 64 bits already.

If you want to publish a book on i386 wait until nostalgia builds up and it finds a place among "a real-time OS for the Zilog Z-80" and "programming your Mac in Motorola 68000 assembly".

Re:Robert Love (1)

Daniel Phillips (238627) | more than 3 years ago | (#33784182)

Some have claimed that open source developers go into Google and disappear. This is correct. I can confirm it from firsthand experience.

Re:Robert Love (-1, Troll)

Anonymous Coward | more than 3 years ago | (#33763808)

1rt = fart

Anonymous Coward (3, Funny)

Anonymous Coward | more than 3 years ago | (#33763474)

Another book about developing a skillset I wish I had. I hate being web developer, I get no respect.

Re:Anonymous Coward (5, Funny)

BadAnalogyGuy (945258) | more than 3 years ago | (#33763560)

If only there were a book to help you build that skillset.

Oh well!

To Earn Respect Accumulate Knowledge (5, Interesting)

eldavojohn (898314) | more than 3 years ago | (#33763596)

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:To Earn Respect Accumulate Knowledge (1)

phantomfive (622387) | more than 3 years ago | (#33764682)

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.

O'Reilly Book Has More Implementation, Less Theory (3, Informative)

eldavojohn (898314) | more than 3 years ago | (#33764846)

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:O'Reilly Book Has More Implementation, Less The (0)

Anonymous Coward | more than 3 years ago | (#33776734)

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.

Re:O'Reilly Book Has More Implementation, Less The (0)

Anonymous Coward | more than 3 years ago | (#33786066)

Socketpuppet much?

Re:To Earn Respect Accumulate Knowledge (1)

Crag (18776) | more than 3 years ago | (#33765582)

"If you don't know C, that's just another thing to learn before starting down this road."

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 hidden by high-level languages.  It is high-level enough to facilitate modern programming styles.  With C you are (mostly) operating directly on the metal, but it provides the abstractions you need to save yourself from repetitive stress injuries.

The following is probably valid C:

void Continuation__call_or_throw(Object obj, String method_name) {
    ContinuationFrame result = obj->lookup_method(method_name);

    if (result->isa(Error)) {
        String error_str = new String(
            sprintf("Error '%s' looking up method '%s' on object '%s'",
                    result->description,
                    method_name->as_string,
                    obj->as_string));
        myContinuation->start_traceback(error_str, result);
    } else {
        myContinuation->add_frame(result);
    }

    myContinuation->resume();
}

C is a little like Latin in that once you know it, you know a lot about every language which was spawned from it.  Even if you never work on a project written in C, you will use what you learn in every other language you learn.  It will also stretch your brain so that whenever you think about an abstract list or array, you also think about linked lists and arrays of pointers.  You don't have to know about these things to use them, but knowing about them makes using them less surprising.  It is impossible to over-recommend learning C if you're interested in programming at all.

Re:To Earn Respect Accumulate Knowledge (1)

DiegoBravo (324012) | more than 3 years ago | (#33767796)

> 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:To Earn Respect Accumulate Knowledge (0)

Anonymous Coward | more than 3 years ago | (#33768748)

Year, if you were writting Web Applications in C then you might risk making them efficient, see how much better ANSI C scripts are doing:

http://gwan.ch/

And this would be a disaster for those who make a living bundling OS licenses with hardware (because C applications require thousand times less servers).

What a sad world it would be, really. Thanks God that we have inefficient languages like Java or C#.

Re:To Earn Respect Accumulate Knowledge (1)

Bungie (192858) | more than 3 years ago | (#33771862)

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 know about. For example, gcc is aware of instructions that can stall the pipeline and will reorder them in it's output to account for this. Someone writing assembly code by hand may not be aware of this, and even if they are they're doing a lot of work that gcc does automatically. The high level runtime environments used by Java and C# also can be improved and thus improve the efficiency of all programs that use them.

It's 2010 and programming should be abstracted from the bare metal by high level languages and libraries. The last thing a guy writing a web app needs to do is start worrying about memory allocation, pointers and string buffers when he needs to focus on sanitizing and safely handling the input.

While C allows the program to work more efficiently, inefficient languages like C# and Java allow programmers to get stuff done much more efficiently. There's just a point where you have to accept inefficient things like XML and make the computer do the extra work instead of the programmer. C's "thousand times less servers" really doesn't mean much anyway these days with everything being virtualized.

Re:To Earn Respect Accumulate Knowledge (1)

jgrahn (181062) | more than 3 years ago | (#33787828)

Things like garbage collection are a nightmare when improperly implemented in a C program, while it's automatically handled in higher level languages.

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.)

There's just a point where you have to accept inefficient things like XML and make the computer do the extra work instead of the programmer.

I can accept a lot of inefficiency (like Python's interpreter), but I refuse to accept stupidity (the majority of all XML use).

C's "thousand times less servers" really doesn't mean much anyway these days with everything being virtualized.

As a C programmer, I have never heard that slogan, but I'm sure it's untrue. Most problems are I/O bound, and C doesn't make I/O faster. On the other hand, I fail to see why virtualization would make performance a non-issue. And electricity and cooling aren't getting cheaper ...

Re:To Earn Respect Accumulate Knowledge (1)

whitehaint (1883260) | more than 3 years ago | (#33767866)

I like the idea of learning a proper language, however the other day I picked up a book on basic web programming (CSS, X/D/HTML, JavaScript) and to be honest the books are atrocious! Knowing how to use the stuff, and seeing the presentation in these books I can see why it is hard to learn new languages with the same people writing this nonsense. I have never seen a simple idea like CSS so overcomplicated. Make a PHP for beginners, with the usual hello world but throw some real world applications and implementations of scripts.

Re:To Earn Respect Accumulate Knowledge (0)

Anonymous Coward | more than 3 years ago | (#33825906)

>>> there's no reason why you can't hack away at home in your spare time.
 
Except that I have no spare time!

Yeah but who gets rich. (2, Interesting)

AnonymousClown (1788472) | more than 3 years ago | (#33763666)

That last couple of get-rich-quick billionaires were web guys.

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:Yeah but who gets rich. (1, Insightful)

Anonymous Coward | more than 3 years ago | (#33763732)

Respect from other developers doesn't buy jets and super models.

...and supermodels and jets don't buy respect from your peers.

Re:Yeah but who gets rich. (1)

AnonymousClown (1788472) | more than 3 years ago | (#33763794)

...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:Yeah but who gets rich. (1)

h4rr4r (612664) | more than 3 years ago | (#33764418)

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:Yeah but who gets rich. (0)

Anonymous Coward | more than 3 years ago | (#33764762)

You are assuming that respect from people who use the word "handegg" has any value to me, let alone more value than jets and supermodels.

Someone needs to check their premises.

Re:Yeah but who gets rich. (0)

Anonymous Coward | more than 3 years ago | (#33764998)

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.

U MAD?

Re:Yeah but who gets rich. (2, Insightful)

Fujisawa Sensei (207127) | more than 3 years ago | (#33765016)

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:Yeah but who gets rich. (0)

Anonymous Coward | more than 3 years ago | (#33769246)

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?

All non-American people care because they have other values besides money.

Re:Yeah but who gets rich. (1)

WhitePanther5000 (766529) | more than 3 years ago | (#33764118)

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 would :)

Re:Yeah but who gets rich. (0)

Anonymous Coward | more than 3 years ago | (#33767920)

Embedded developer has actually a better average than both which means I *will* get rich... If I move to America :p
I am happy enough to be able to use C instead of Java, C# or Javascript. On the other hand, I probably wouldn't have to use Excel as a bug tracker if I was hacking the Linux kernel. That might well be worth the average $5000 difference.

That whole site is worth posting just for this:

prostitute
        $66,000
Average prostitute salaries for job postings nationwide are 1% lower than average salaries for all job postings nationwide.
Average Salary of Jobs with Related Titles
Police Officer
        $46,000

Re:Yeah but who gets rich. (1)

WhitePanther5000 (766529) | more than 3 years ago | (#33770946)

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:Anonymous Coward (1)

amanda5211 (1915578) | more than 3 years ago | (#33803512)

[url=http://www.jerseys-2010.com/wholesale nfl jerseys[/url] [url=http://www.jerseys-2010.com/cheap nhl jerseys[/url] [url=http://www.jerseys-2010.com/football jerseys[/url] [url=http://www.jerseys-2010.com/nba shop[/url] wholesale nfl jerseys [jerseys-2010.com] cheap nhl jerseys [jerseys-2010.com] football jerseys [jerseys-2010.com] nba shop [jerseys-2010.com] [url=http://www.hatonsale.com/winter cap[/url] [url=http://www.hatonsale.com/red bull cap[/url] [url=http://www.hatonsale.com/monster hat[/url] [url=http://www.hatonsale.com/new era hats[/url] winter cap [hatonsale.com] red bull cap [hatonsale.com] monster hat [hatonsale.com] new era hats [hatonsale.com] Monster Energy Hats [hatonsale.com] Dc Shoes Ken Block 43 Ford Monster [hatonsale.com] Dc Shoes Ken Block 43 Ford Monster [hatonsale.com] NBA Detroit Pistons [jerseys-2010.com] Reebok NFL Jerseys Philadelphia Eagles [jerseys-2010.com] Kids Kansas City Royals PHILLES [jerseys-2010.com] http://www.jerseys-2010.com/ [jerseys-2010.com] http://www.hatonsale.com/ [hatonsale.com]

BETTER BE FREE !! Hyporcrite if is PAY !! (-1, Troll)

Anonymous Coward | more than 3 years ago | (#33763482)

Better be free, or those GREEDY BASTARDS are just another in a long list of GREEDY BASTARDS !!

Just do it (1)

sqldr (838964) | more than 3 years ago | (#33763818)

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

AAARGH!! (1)

sqldr (838964) | more than 3 years ago | (#33763864)

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 (1)

Giant Electronic Bra (1229876) | more than 3 years ago | (#33764068)

I mean really, you gotta give those Russians a break you know. They have the Chinese to compete with!

Re:AAARGH!! (2, Informative)

maxume (22995) | more than 3 years ago | (#33764452)

There is a preference for it, you can set your own default.

Re:Just do it (3, Informative)

skelly33 (891182) | more than 3 years ago | (#33765936)

I know this is tangential to your point, but...

"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:Just do it (1)

sqldr (838964) | more than 3 years ago | (#33770582)

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..." (4, Funny)

onionman (975962) | more than 3 years ago | (#33763940)

"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' (1)

eldavojohn (898314) | more than 3 years ago | (#33764546)

"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:Well, It's Either That or 'tl;dr' (1)

abigor (540274) | more than 3 years ago | (#33765478)

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:Well, It's Either That or 'tl;dr' (1)

onionman (975962) | more than 3 years ago | (#33765622)

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:Well, It's Either That or 'tl;dr' (1)

iceaxe (18903) | more than 3 years ago | (#33765848)

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! (1)

whoop (194) | more than 3 years ago | (#33764208)

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... (1)

emanem (1356033) | more than 3 years ago | (#33765138)

...Now!

Cheers,

Non-x86? (2, Interesting)

wowbagger (69688) | more than 3 years ago | (#33765538)

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 (3, Interesting)

eldavojohn (898314) | more than 3 years ago | (#33766226)

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:Answers (2, Insightful)

Cylix (55374) | more than 3 years ago | (#33767392)

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 understanding the technical limitations when providing the correct stream of data to the device.

I think a good kernel book will help to understanding developing for the vid4linux interface, but it doesn't help so much when you need the chip information to actually make it go.

Re:Non-x86? (1)

Cylix (55374) | more than 3 years ago | (#33767362)

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 timing to consider. (depends on how bare metal you operate).

There needs to be some specific reference to what you want to accomplish in order to provide insight. I'm quite certain my mind is already swimming in some far dark corner that you are not even concerned with.

More than just Amazon (1)

stovicek (1768794) | more than 3 years ago | (#33776268)

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 [powells.com]
Indiebound [indiebound.org]
Barnes & Noble [barnesandnoble.com]
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>