Slashdot Mirror
Linux Core Kernel Commentary
What's to Like? Most interesting for me was the "a-ha!" factor. The normal chapter flow describes the subsection in general terms (memory management is designed to do such and such, with these issues), moves to the important data structure, and then walks through the vital functions for that section, stopping here and there to explain peculiarities and subtleties of the code. There's rough going in a few spots, but there are occasional moments of insight where the solutions come in to clear focus. (This happened most often for me in the SMP chapter, as the discussion of locks is particularly good.)
Maxwell manages to avoid unexplained jargon for the most part, though he invents names for implied kernel idioms. Even while dealing with highly specific topics, readers won't need a background in OS design to understand the text. Good C skills will help, as well as assembly, though the latter is explained in greater detail than the former.
The author also takes pains to point out flaws and possible optimizations in the kernel, though he often concludes that the route taken is the best for various reasons. Another theme is the tradeoffs necessary between speed, clarity, compatibility and portability. Finally, as kernel 2.4 will be out shortly, Appendix B discusses the modifications in the 2.3 tree as it went to press.
What's to Consider? As space is limited, Maxwell sometimes skips some interesting details -- especially in latter chapters. Unfortunately, phrases like "There's not room to cover this" or "that is out of the scope of this book" pop up now and then. I definitely wanted more.Two other small nitpicks may be corrected in a future version. First, it would have been nice if the current filename was listed on each page of the source code listing, just for reference. Second, flipping back and forth between commentary and code was tricky, especially in a book of this size. Perhaps splitting things into two books would help? Serious students might find it easier to browse the code from the CD-ROM, which includes the code for kernel versions 0.01, 2.2.5, 2.2.10, 2.3.12, and the entire code of the first section, numbered as it appears.
The Summary This could serve as a textbook in an OS design class. Supplemental material will be necessary (file systems not covered for example, nor are drivers). Perhaps paired with a more theoretical text, it could form the basis of an intermediate computer science class.The utility is not limited to students, though. Anyone wondering where to start understanding the Linux kernel would do well to consider this book.
Buy this book at ThinkGeek.
Table of Contents- Linux Core Kernel Code
- Linux Core Kernel Commentary
- Introduction to Linux
- A First Look at the Code
- Kernel Architecture Overview
- System Initialization
- System Calls
- Signals, Interrupts, and Time
- Processes and Threads
- Memory
- System V IPC
- Symmetric Multiprocessing (SMP)
- Tunable Kernel Parameters
- Appendices
- Linux 2.4
- GNU General Public License
that they sell the sourcecode to the Linux kernel in the bookstores? I saw that the other day, and was amazed.
/. is a commercial entity. goto slashdot.com
Sorry to say this, but alhough a book like this is actually a good idea, the presentation seems a bit silly; why print over 40.000 lines of code, while at the same time they are included on CD (or in most people's Linux distribution for that matter). This looks like a massive waste of trees, a more interactive way would be an good initiative.
How to make a sig
without having an idea
I flipped through this book one day, and I must say that it seemed to be a pretty good reference. But I'm not sure if it's worth the money when there are good references online. Also, the book covers one version of the source code. As the kernel source is constantly evolving, it will only remain accurate for a short period of time. Plus, you lose the ability of quickly searching files that is available with most text editors.
This is just the sort of thing that Linux doesn't need! The art of kernel hacking is one that truly marks you out as an 31337 h4X0r, and the very last thing that us gods want is for every pean with a c compiler to think that they are worthy of "contributing" to our wonderous edifice!
In the name of Linus, I implore you to boycott this book, else the entire caste system of Linux h4X0r5 will come crumbling down. The future is in your hands.
So a book like this is a blessing.
Though typing the kernel code in all by hand, so that I can compile the kernel and boot Linux on my CDless 486 is a bit of a bother.
Let's see, I'm up to 137 lines, only 39863 to go!
George
Is this book really a good place to start? I'm a novice C programmer, who hasn't really programmed anything since taking C and assembler for VAX/VMS in college back in '92.
Perhaps this is covered in the historical section of the book, but one task I've thought about try is to re-invent the wheel and try to build a linux system from scratch with just the kernel. I've always been curious about how the development of an OS starts...I mean take a raw disk with no filesystem and your basic computer and how do you go about building an OS like linux? I would assume you need to understand the boot process and what it is that must be done when the machine boots.
Over the passed couple of years I've worked with RS/6000s and I've found it quite interesting that IBM can boot any of their machines - Microchannel or PCI based - from an AIX install CD, but none of the PPC linux distros can seem to create a bootable CD Image. I'd really like to delve into the basics of the Kernel and how it boots a machine boots to help with the PPC folks in getting a bootable install image.
...except for the shipping charges. I agree that the 37k lines of source may be a waste of trees, but it is easier to flip through a book sometimes.
A good companion to this book is Advanced Programming in the Unix Environment. I found myself wondering exactly why some kernel routines were implemented the way they were, until I read up on them in APUE. It's important to understand the "user" interface to the kernel when you're reading this book.
Knowledge of stuff like assembly language (GNU's version of course) and low-level stuff like IRQs/interrupts, memory segmentation, and device IO is important--like the review says, he doesn't go into those details. Higher-level stuff like scheduling, file-system calls, and IPC is dealt with very well.
then don't buy the book. look through your technical book collection, and count the number of scribbles. If your books are like mine there's probably a comment i wrote to myself every few pages. While yes, I could just comment the code, and keep it in a source tree, I can't do that while I'm sitting in a park, enjoying not being near a computer.
----------------------------
It's not about understanding the absolute latest kernel source. The book doesn't get rendered obsolete because we went from 2.2.12 to 2.2.15 or even to 2.4.0pre5000. It's a book for understanding the basics of how the kernel works, why things are structured as they are, and to learn about this design, thus making it so that you may be able to understand the latest version of the kernel.
And those of us who know what in the kernel we want to quickly search a file for, in order to learn about Linux's memory management for example, have quite probably already read and understood the source code, so therefore have no use for the book anyway.
----------------------------
I studied under John Lions and used his commentary of the level six UNIX. He included 9600 lines of code and every single one of them had a commentary to go along with it. It also had a functional cross reference for jumping around the code. This book went back the next day. It's not useful for the majority of people.
- AndrewN
You mean kfirstpostd? It's in 2.3.99pre147-3-2-almostready-ac32
or maybe kslashdotd? It's a more general solution, but it won't be included until 2.4 is fully out, and the 2.5 tree starts.
At my university, there are several professors that require this book for the advanced operating system design class.
The class has been taught using linux since about version 1.something, before that it was MINIX I believe.
All of the students that have taken that class, (and read this book) have been very pleased with it, but I've heard many times that you shouldn't even bother looking at it unless you feel fairly comfortable with your C.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
I am wondering if this book is really necessary. Since Alan Cox and other core kernel developers are working on commenting the kernel themselves I don't really see the usefulness of this book.
Personally I would much rather learn how the kernel works from the actual kernel developers than anyone else. ( I don't know if Mr. Maxwell contributes to the kernel, but I have never heard of him.)
If you want a paper version (which is sometimes better then a computer screen) just write a little script that recursively descends the kernel directory hierarchy and prints each *.h and *.c file.
IMHO this is not the place to start. I don't know you, so I don't know how comfortable you are with C, but I don't think this is the book to polish your C with.
Lots of people are familiar with C on one level, but not on others. Lots of people can write functions to do things like print to the screen, manipulate numbers, deal with dynamically allocated memory and such, but there are also other levels of C since it's so low level.
For example, do you know how to do bit manipulation? Do you know the difference between & and &&, between | and ||, and between ! and ^? I haven't looked into the kernel source too much, but if you don't know how to do that stuff, you may not enjoy the book. Also, there are other "conventions" in C that it helps to be familiar with, that don't make any sense until you get some experience under your belt. (Example there would be in C some functions rather than taking 20 boolean arguments, take 1 argument that is just a bunch of packed bits, and then checks that argument to see if a particular bit is set instead of taking an argument in that spot - X11 does this a lot, and when I first saw it, I thought it was pretty stupid. (Turns out its not)
I think in order to bone up on C again it probably wouldn't be a bad idea to first read some generic source code to something easy until you understand it all, and then tackle the kernel instead of starting back into C with kernel code.
I've also heard that certain parts of the kernel are extremely cryptic because they've been hand-optimized for speed, but I don't know how true that is. (It would make sense though) in cases like that, it may be difficult even for people who know C really well to grok that code.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
OTOH, if you're not familiar with how operating systems work, I think you'd do better to start with John Lions's Lions' Commentary on Unix: With Source Code, (Peer to Peer Communications 1996), ISBN 1573980137.
This book, usually called "The Lions Book," has the full source code for an early version of Unix, followed by Professor Lions's annotations. The source and commentary are comparatively short (about 300 pages, compared to 400 pages for the Linux source alone), largely because the kernel it describes is a good deal smaller than the current linux kernel. This means it's also a lot simpler than the linux kernel.
If you're already comfortable with reading complex sources, and you know a lot about operating systems, then give Maxwell's book a try. But I suspect a lot of people would be overwhelmed by it, and the Lions Book is a better place for them to start.
Notice that the User has a period in the front.
Hal Duston
hald@sound.net
Boring is good. A conformist in a nonconformist world
While the commentary might be good, the book's half-assed ripoff of the format of the old Lions commentary kills the usefulness of the book:
I always thought that Lions' commentary used that format due to AT&T licensing restrictions on the source code, or some other AT&T policy. But Coriolis had no such excuse in writing these books. With open source projects, this layout stinks.
On the whole the book was only marginally more convenient than printing my own copy of the source code. I would not recommend it. Better to get cscope (free now!) and a different reference. [For Apache, try O'Reilly's "Writing Apache Modules", with decent API docs.]
And you may ask yourself, well, how did I get here?
Nah. The above only works for a kernel upgrade (how else could you be using cat?).
And two other points:
dd of=/dev/hda
to modify their boot sectors.
Geez. These commercial Linux distibutions are making it just too darned easy.
--
CUR ALLOC 20195.....5804M
--
... where I hung out, there were these nice shiny new m68k Sun whelkstations -- someone lusted after the then new 386-based Roadrunners, but we'll forget him -- and there was a persistent rumour that one amongst us, his identity a dark secret, could hack his way to root status in under 90sec starting from % in a vanilla account.
It is also true that among us was one Alan Cox, an Amiga aficionado, who liked its OS, and used to do stuff to it so he could make the sound ASICs perform, as he put it, "chickens in minor sevenths". And Amigas were m68k-based.
I suspect that having the source code to look at, commented or not, is not enough for most of us, and having a fat commentary to advise us what we should be looking at, and whereabouts, will be a great boon to newbie kernelistas.
After all, I was an Atari ST aficionado, and they were m68k based, yet I never quite managed to perform an illegal su. The likes of Cox seem to be special, but let's not let that stop us from aspiring to bug-free kernels of our very own.
The whole thing reminded me on that linux-source-navigator I found on the web.
But it didn't get changed since 1996 it seems.
Something like that would be very useful,
with some more basic theory explained.
-- chrisse
Another excellent reference to learn about Operating Systems in general is Tannenbaum's 'Modern Operating Systems'. It's a well written text which covers operating system concepts thoroughly without making things unneccessarily complex.
In my initial comment I had assumed that anybody who would attempt to work on the kernel would have already made themselves familiar with general operating concepts through a book such as the ones mentioned by each of us. I'm not familiar with the text you suggested, however.
----------------------------
I'm familiar with OS basics, and have even written a couple of executives for embedded systems. Right now I'm in the middle of my first project actually working on the Linux kernel.
I tried reading through the source code, there are a lot of things that while obvious once you know what they are, aren't documented in an obvious place in the source code. The kernel does need better documentation. I would love to have time to go through and add manpage style headers to at least the important functions. Headers that detail the gozintas and gozoutas, as well as what the function basically does.
In the meantime I've used several books to help figure out what was going on. Each one has various strengths and weaknesses. This one is good for the functions that are actually documented in this book. The separated code and comments make it a nuisance to flip back and forth, but it does make the code more readable. It also makes the footnoting a little more versatile. Unfortunately for me, some of the areas that I needed the most help on were new to 2.2 and this book documents the 2.0 kernel.
Rubini's book on Linux Device Drivers is excellent. It is a "must have".
Coriolis also publishes the Linux Programming White Papers which collects several Open Source documents in one handy deadtree collection. Being a big fan of documentation that I can leaf through, I've found it quite usefull.
The Linux Kernel Book by Card, Dumas, and Mevel has good documentation on all of the various structs in the Kernel. It is also a decent high level overview.
I did not get the Wrox book on Beginnin Linux programming, so I can't accurately comment on it's usefullness.
Thinkgeek selling the books slashdot is featuring just doesn't feel right to me. It's a great idea, but, I guess anytime people I trust (like slashdot) have multiple reasons for helping me (even if it is just by providing information) it bothers me.
Slashdot's authors, even before they started working for Andover, made it completely apparent they were looking for sponsers, and monetary support. Just because they make a blatant promotion on thier site for ThinkGeek doesn't mean they aren't to be trusted, that's how this site stays up dude.
No offense but if you are looking for a completely non-promotional news site, you've come to the wrong place.
Sorry. :-)
--
-Rich (OS/2, Linux, BeOS, Mac, NT, Win95, Solaris, FreeBSD, and OS2200 user in Bloomington MN)
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Y'all might be interested in LCKC's home page, which includes links to other reviews, an errata list, and an improved index donated by a generous reader. You can also email me about the book.
--
``Life results from the non-random survival of randomly varying replicators.'' -- Richard Dawkins
Plain old magnet for me, although dragging inodes manually around a hard disk after a few cups of coffee can be tricky, quite hard to keep your hand steady :)