Become a fan of Slashdot on Facebook. That works out to two columns on each of over pages. It's mostly free of annotations, except for small arrows referring to the commentary on that section. The commentary takes up the rest, at three columns per page. The architecture dependent functions target x86 code, and the core features memory management, processes, scheduling, signals and threads, procfs are covered. What's to Like?
|Published (Last):||9 July 2008|
|PDF File Size:||9.78 Mb|
|ePub File Size:||4.44 Mb|
|Price:||Free* [*Free Regsitration Required]|
Become a fan of Slashdot on Facebook. That works out to two columns on each of over pages. It's mostly free of annotations, except for small arrows referring to the commentary on that section. The commentary takes up the rest, at three columns per page. The architecture dependent functions target x86 code, and the core features memory management, processes, scheduling, signals and threads, procfs are covered.
What's to Like? Most interesting for me was the "a-ha! 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. 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. 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. 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 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. You have chosen the true path, my friend. Only those who type in the entire program, like those of us Antic subscribers who did not own an Atari tape drive and therefore had to type in everything we wanted to run, can appreciate what a program truly does. That way, you can compile in a second window and watch for faults.
On the other hand, you could always go the true route and use ed! I am wondering if this book is really necessary.
Since Alan Cox [linux. 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. 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 pages, compared to 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.
The above only works for a kernel upgrade how else could you be using cat? 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. But it didn't get changed since it seems. Something like that would be very useful, with some more basic theory explained. That's also good. This is the ideal book for someone who's studied operating systems in school but has never seen real source code.
This seems to be the case for most folks I see that are new holders of a B. Theoretical descriptions in texts frequently skip the messy parts otherwise, they might as well print the source code! Once you've seen an example of how it's done with a few helpful annotations, you're better able to deal with other systems that are implemented differently.
I've seen a lot of online kernel documentation, but there isn't any of it that I'd point a new team member at in preference to this book, unless the thirty bucks was an issue.
On the other hand, if said new team member is already a BSD kernel hacker, there will be much less benefit to reading it. I did find a few clangers while I was browsing through it. For example, the author seems to think that the top half of a driver is the same as the hardware interrupt handler. Y'all might be interested in LCKC 's home page [scottmaxwell. You can also email me [mailto] about the book. 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 :.
When he spoke about the language, he really knew what he was talking about. Alan filled me with a passion for C, although I doubt he knows it. There may be more comments in this discussion.
Scott Maxwell might end up as the guide for a fresh batch of aspiring programmers, with his Linux Core Kernel Commentary. Starting with a lesson on the history and philosophy behind free software, you can learn enough to start contributing on your own.
This discussion has been archived. No new comments can be posted. More Login. Did you know Score: 1. I saw that the other day, and was amazed. I'm sorry for the trees! Score: 1. Sorry to say this, but alhough a book like this is actually a good idea, the presentation seems a bit silly; why print over 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. Re:I'm sorry for the trees! I don't know how most people feel about computer books and other books for that matter , but there is definately something very different about reading it in a book and on a computer screen. I, for one, seldom will look at a book and its included cd at the same time. I like it when a book will present code examples and then go through them, I imagine that this is close to what the author and publisher thought.
Worth the money? Score: 2. 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.
Linux Core Kernel Commentary [With CDROM]
The Commentary on Unix helped to spread the Unix source - and the Unix way of doing things - when that source was still at least intended to be proprietary. The Linux Core Kernel Commentary finds itself in a very different environment; the kernel source is, of course, already widely distributed throughout the world. This is a heavy book, weighing in at pages in a large format. Of those pages, go toward printing just under 40, lines of source from the 2. The source code listing is pretty much what one would expect it to be. Numerous source files from the "core" part of the Linux kernel are printed, all together, with line numbers.
Linux Core Kernel Commentary
What's to Like?
Linux Core Kernel Commentary, 2nd Edition