Understanding the Linux Kernel 96
Understanding the Linux Kernel | |
author | Author: Bovet, Daniel P. / Cesati, Marco |
pages | 684 |
publisher | O'Reilly & Associates |
rating | 8.5 |
reviewer | John Regehr |
ISBN | 0596000022 |
summary | The guts of the kernel, labeled and explained. |
Although isolated pieces of operating system internals are usually not difficult to understand, learning how a significant portion of a real OS works is a daunting task: there's a lot of code, some of it is complicated, and some of it operates under obscure assumptions that can be difficult to figure out by reading the sources. Two of the best existing books about OS internals have explained either a simplified but working OS (Tanenbaum's Minix book) or a real, but very small OS (Lions' book on Unix v6). Although these systems have the advantage of being easier to understand, there's an important reason why one might want to study Linux internals instead: Linux is currently relevant, it's likely to be around for a while, and any code you write can potentially be used by thousands of people the day after tomorrow. So, taking it as a given the a book about Linux internals is a good thing, how good is this one? Happily, it's very good - better than any previous such book that I've seen (Rubini's Linux Device Driver book is also excellent, but it has a limited scope).
Understanding the Linux Kernel is good for several reasons. First, the authors have included quite a bit of explanatory material that isn't specifically about Linux - it's the kind of thing one would find in a good undergraduate OS textbook. This helps the reader link explanations of pieces of code to the abstract OS functions that they implement. Second, the authors have chosen a good level of abstraction: core kernel algorithms are explained in text, supplemented with short code sequences (simplified to remove optimizations) for important routines. Flowcharts are used to explain components with complex control flow, and tables and other diagrams are used when appropriate. Finally, the book is well arranged and well written, and there's an auxiliary index at the end that maps symbols mentioned in the book to source code files.
There are a few things I don't like about this book. Most importantly, there is no discussion of the network stack. As the authors say, this is a subject for another book, but by leaving out one of the most interesting and relevant parts of the kernel they are limiting their audience. A second drawback of this book (and of any Linux kernel book) is that since it seems to take about as long to write a good book as it does to write a major version of the Linux kernel, as I write this review it's about to become obsolete - it describes Linux version 2.2. However, at the end of each chapter there's a short note about things that are done differently in version 2.4. This will help preserve the relevance of the book after 2.4 comes out and, maybe more importantly, it gives the reader a sense of what parts of the kernel are under active development and what parts have become mature and stable.
Although Linux is very much in the Unix tradition, many details have changed. For example, early Unix kernels used simple algorithms (such as linear searches) and fixed table sizes. Modern Linux kernels, on the other hand, avoid arbitrary limits on the numbers of many kinds of internal OS objects, do not use linear searches when the number of objects to be searched is potentially large, and use amortized algorithms in many places. In all parts of the kernel, any special knowledge about the way that OS services will be used is exploited in order to improve average-case performance. For example, the slab memory allocator makes use of the fact that kernels often allocate many objects of the same size in order to reduce memory fragmentation and to avoid creating hot spots in the data cache. These algorithmic optimizations are much more pervasive (and much more effective) than micro-optimizations such as tuning register allocation or packing flags into the bits of a memory word - they're what make Linux useful in large-scale server environments where high throughput is critical. However, they also make the kernel code quite a bit more difficult to understand.
Given this complexity, it seems reasonable to ask who needs to read this book and how well does it suit their needs. Three groups of people come to mind. First, potential kernel hackers will find this book to be a good overview of different parts of the kernel. Of course, for people like this a book is no substitute for lots of code reading, but it's a good start. Another potential audience is the group of people who need to understand the kernel in order to extract high performance from it; for example, authors of databases or network servers. This group's needs are well served by this book: the authors often point out why certain heuristics were chosen - this may help people whose applications have run afoul of a resource allocation policy that was designed to serve a different class of applications. Finally, computer science students interested in the internals of a real OS would do well to read this book. It would make a good supplement to a standard OS textbook in an introductory class on operating systems. However, Linux appears to be far too large to understand in its entirety in a single semester: classes that attempt to do this should use a teaching OS like Minix. To benefit from this book, readers should have knowledge equivalent to a couple of semesters of computer science: a basic understanding of programming, of the services an OS provides to user-level programs, and of the hardware mechanisms used by an OS.
This is a good book. The authors have cracked open a large collection of code that's currently very relevant. If they are in for the long haul and release revised books in a timely way, then this will likely become and remain the definitive explanation of Linux internals.
The web site for the book is here.
You can purchase this book at Fatbrain.
Re:Under the hood (Score:1)
Third, I thought I was clear on this: I wasn't talking about the kernel. I was talking about the dangers of breaking an implementation by working around the interface, something that can easily happen when the programmer in question knows too much about implementation-specific details. This is a trap that yospelld not standardized. This is an example of something that I would have liked to see standardized, and something that a programmer might end up having to work around.
I do like your malloc() wrappers; those could potentially be pretty handy. But I can't necessarily expect all memory allocated in a program and passed to a function to use those.
Oh, and I wouldn't call your moderator "an cueless asshole", just in case they still have some mod points, and happen to be a spelling nazi as well.
Cheers,
Peter
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:Under the hood (Score:1)
This stuff *does* change from one version of libc to the next, and I've *seen* demons get created from code like this! (didn't I say it was unspecified?) That's why I wish there was a function call that did this for me, in the C library. (there's sizeof(), but that doesn't work!
And yes, as many have pointed out, what you can also do is pass a region of memory, and the size that you think it is. That's all fine and dandy until (a) someone lies to you or (b) all you have is a pointer to some unknown amount of memory. It's easy to do, and it will happen to you someday.
Also, I stopped posting on USENET once it started getting spammed to hell and back, although I'm sure those groups are still moderated. I used to post to comp.lang.pascal.misc, until about when they reorganized the whole thing and created all the stupid delphi groups. But maybe I'll check it all out again sometime, since Slashdot sucks so much.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Yeah. (Score:1)
But what if you want to know how large a memory structure is, and don't want to truncate it? It can happen.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:Under the hood (Score:1)
If I ever need it, I'll try implementing it for different C libraries on different platforms.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:Under the hood (Score:1)
But yes, the best theoretical use for something like this would be for memory coming from outside your program, or into your function when you do not already have knowledge about it. I know that C can do it, because functions like realloc() make use of this information; I just wish I could as a programmer.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:Under the hood (Score:1)
So, of course you can have a pointer handed to you that wasn't directly from malloc(); I'm sure the function in question would have to have that in huge letters on the documentation, somewhat like fgets().
I'll have to lurk in trolltalk some more; I haven't posted there in a while. How time flies; I started the one on kuro5hin, and that's already dead...
And yes, I've obviously been karma capped for way too long; it's at 252 now, from 350 originally... But who cares, right?
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:Under the hood (Score:1)
I think you mean snprintf().
--
Re:I've already taken a look at this book.. (Score:1)
Re:Under the hood (Score:1)
That would only be true if you had unlimited swap space.
Re:Windows source (Score:1)
Unix Internals: thumbs down (Score:1)
IMHO, Vahalia's "Unix Internals" is not worth 61$. It's dated in the sense that it doesn't really talk about the "modern" PC Unixes (e.g. FreeBSD and Linux) at all. If you want to know how the current system that you're running right now works, this book is just too old.
If you really want to know about performance tradeoffs, get a more CS-oriented book (e.g. Silberschatz, Tanenbaum, etc), not a Unix-only book from 1996.
---
Another good'un (Score:1)
As for windows source code, all it'll cost ya to look is an NDA from hell, and possibly your first-born male child...
Re:The smell of O'Rielly (Score:1)
--
Re:This is a very good book (Score:1)
I spun around on my chair until I fell off. When can I expect you to send me a copy?
--
Re:Windows source (Score:1)
Eric
Elder Tomes of Knowledge (was Re:Windows source) (Score:1)
it's not THAT hard to see windows source. (Score:1)
1. Sell your sould to Sat*coughbillgatescough*an
2. sacrifice your firstborn to the almighty BSOD
3. kill a linux programmer and bring his brain to M$ headquarters.
you will then be allowed to see the windows source. However, they will kill you if you laugh at the fact that windows has a whole lot of this(uhh, i don't know C so here it is in a sort of messed up pseudo language form:
while foo > 0
if condition.unknown=true
then goto BSOD
next foo
or something like that
----------------------
Book on Windows Kernel (Score:1)
Oh, I forgot. You don't care about facts when bashing Windows - this is Slashdot.
Re:Reviewer on Crack (Score:1)
Re:1st read (Score:1)
Re:The smell of O'Rielly (Score:1)
They have a nice texture, I've never noticed the smell though.
There's nothing like coming home from a nice workout all sweaty and settling down for a nice night of paging through O'Rielly techincal manuals
If you're all sweaty, you've probably gotten sweat all over the pages which is what is giving them that smell you like.
How about applicability towards an OS class? (Score:1)
I wonder whether this would be a good "textbook" to teach the practical aspects of an OS, and then relate it to a "standard" OS (rather than the Older Unices, or VAX systems).
Any comments or thoughts from that aspect?
I bought it (Score:1)
I have this book and I find it too be less technical and much more abstract then I had hoped. If your intent is to make kernel modules et al, buy Oreilly's "Device Drivers" book and not this. If you wish to have a general understanding of the kernel, but be abstracted away from the code buy this.
One warning, it is very, very dull.
Re:Unix Internals: thumbs down (Score:1)
That's funny. If you read the Vahalia book and the Linux internals book reviewed here, you would notice that a lot of the stuff that Vahalia talks about (e.g slab allocator, SysV memory management integrating buffer cache and page cache etc), is just now being integrated into the Linux kernel. In fact I even remember seeing some parts of the kernel referring to the Vahalia book as the primary source of information... (just grep through the source for vahalia). In fact I would go so far as to say that for a lot of Linux kernel subsytems, as they exist in version 2.4, Vahalia book is an excellent reference. The two books I mentioned above nicely complement each other.
Ciao
Re:Under the hood (Score:1)
size_t _msize( void *memblock );
Not ANSI tho.
Re:cost? (Score:1)
No, you just have to live in Seattle. With so many contractors working for the velvet sweatshop you can't walk down the street with out tripping over some former contractor/slave that is holding up a sign that say, "Will trade W2K source for food."
But seriously, several years ago we found a deep problem that micro$oft had no interest in fixing with NT, nor could we wait for their next release cycle even if they would, so we had everybody in our little company ask around and sure enough somebody was in the church choir with a micro$oft employee who knew the person who worded on that part of the code. We got the source under the table, fixed the bug, returned the fix and the fix now lives in the NT source tree. Not what I would call open source, but it saved our butts.
Re:Under the hood (Score:1)
Not to be picky, but part of the reason sizeof doesn't do what you want is that it isn't a function--it's an operator.
Re:Under the hood (Score:1)
Interesting (Score:1)
Re:1st read (Score:1)
The book you want is "Unix Internals" by Uresh Vahalia. It is fantastic. It walks you through the evolution of Unix and talks in detail about the distinguishing features of Solaris 2.x, 4.4 BSD, Digital Unix, SVR 4.2 and Mach among others.
Re:How about applicability towards an OS class? (Score:1)
Yes, it does refer to an "Older" Unix (MINIX, natch), but then that means things can be kept as simple as they need to be. The information in the book should be transferable to almost any operating system though.
I should imagine that if you combined this book along with OS Design & Implentation, then yes, you would have plenty of relevent information that can be applied to Linux.
Cost to look at windows source (Score:1)
Only one soul. A small price to pay.
Mark
RMIT IT Test Lab Engineer
Re:Funny (Score:1)
Also, Macs don't suck. The PowerPC architecture is revolutionary and (I think) aesthetically pleasing. It is the MacOS (=9) that sucks.
Funny (Score:1)
BTW if you read this book you'd know that Linux doesn't load the "legacy junk" unless you have the hardware in your box. Can you say "pH33r d4 kernel m0dule5?"
Re:1st read (Score:1)
Can anyone recommend another book that would be a good bridge to this one (Understanding...Kernel) for someone who knows only basic high level programming but is interested in surveying the scene "down there"?
-Erik
Re:The smell of O'Rielly (Score:1)
While Tim O'Reilly goes around pretending to be a champion of open source, their outlandishly priced (and inferior) software (WebBoard - 1799$/$2999, WebSite Professional - $995) is anything but. Until they practice what they preach, I refuse to buy anything from O'Reilly. My copy center copy of this book is really good, though - highly recommended introduction to the kernel. Kudos to the authors!
Re:Another good'un (Score:1)
cost? (Score:1)
question: is control controlled by its need to control?
answer: yes
Re:it's not THAT hard to see windows source. (Score:1)
loop:
if(bConditionUnknown == TRUE)
goto BSOD;
if(foo == 0)
goto out;
goto loop;
out:
(Sorry 'bout the lack of indentation
I don't know what the code for boolean is in that LPRSZ stuff Windows API is using, so I made a guess
Re:Cost of seeing windows source... (Score:1)
Cost of seeing windows source... (Score:1)
Besides, if you're knowledgeable enough to be understanding OS source, you shouldn't be stuck with windows anyway, unless you're one of those poor schmucks who is forced to develop with visual studio.
Cost (Score:1)
(I wonder what it costs to look at the Windows source.)
Your soul
m
Re:Under the hood (Score:1)
Um, you really don't ever want to do that. The right (portable) way is to pass both a pointer to the malloc'ed area and its size to your function. What you discribe above can break from one version of libc to the next. Not to mention cause undefined behaivor (according to the ISO standard) and additionly may cause demons to fly out of your nose!
If this was posted on comp.lang.c you would quickly be flamed until you saw the error of your ways ;^)
"I wonder what it costs to look at the (Score:1)
Re:The smell of O'Rielly (Score:1)
---
Kernel & Extfs Links (Score:1)
Concrete Architecture of the Linux Kernel [uwaterloo.ca]
http://plg.uwaterloo.ca/~itbowman/CS746G/a2/
The Linux Kernel Hacker's Guide [redhat.com]
http://khg.redhat.com/HyperNews/get/khg.html
The Linux Kernel [linuxdoc.org]
http://www.linuxdoc.org/LDP/tlk/tlk.html
Analysis of the Extfs Filesystem [polymtl.ca]
Analysis of the Extfs Filesystem http://step.polymtl.ca/~ldd/ext2fs/ext2fs_toc.htm
________
The smell of O'Rielly (Score:1)
Has anyone besides me ever noticed that O'Rielly books have the paper with the best smell and texture. It's light, almost trancelucent, but stiff and sturdy. There's nothing like coming home from a nice workout all sweaty and settling down for a nice night of paging through O'Rielly techincal manuals. C'mon people, I am not alone in feeling this way, am I?
Only slightly OT... (Score:1)
And, *if* you live in Vancouver, BC, check out London Drugs: they're selling copies of this book for ~$20 inc. tax. Just picked up mine...
Re:I've already taken a look at this book.. (Score:1)
About the book (Score:1)
Seems like a sweet book, I own the BSD devil book, while ocasionally i can decypher something out of it, it ususlly makes my head spin. Does anyone know if this book is someone more geared towards a laymon, maybe a guide rather then a reference? Also i wish they would make a book that was like a "stroll through OS design" cover the differences between OS's, what choices they made, how it effects performance, scaleability, etc.. Linux 2.2 is pretty 0ld sk00l compared to Solaris and FreeBSD.
Once you start tinkering under the hood, there's no turning back. There are a few things that I'd love to be able to do in C, but the way to do it isn't standard across platforms or compilers. I can figure it out, but I'd have to test it on *everything*, or only support a few platforms where I know enough about the internals. For example: let's say you have a function that gets passed a region of malloc()'ed memory. You want to know exactly how much memory you have to play with. That number is stored somewhere before the beginning of that pointer. malloc() allocates a little extra memory, writes some status info at the beginning, sticks the pointer in front of that, and returns the address to you. However, exactly where and what it writes are somewhat unspecified. I'd love to have a function in C that did this for me, but alas, there isn't one. So what I have to do is seek back through before the pointer, hope everything is allocated, and look for something like status info. I've done this on Solaris and Linux, and they don't do it the same way. :)
I think stuff like this is fascinating, but using internal knowledge to write your programs can be dangerous; it must be done carefully to avoid breakage.
I wonder why there hasn't been a good book explaining at a high-level how the kernel works with the rest of the files in a particular distro. Of course, there would need to be diferent books for each distro, but for those of use who are still learning how it's all wired together it would be illuminating. Even a decent flowchart would be a nice tool.
Re:Reviewer on Crack (Score:1)
There were clear publishing and printing errors in that book, which made me question the validity of the information therein.
I forwarded my concerns about this to the publisher, who said nothing.
Re:cost? (Score:1)
(I wonder what it costs to look at the Windows source.)
Just your soul [microsoft.com].
Actually, that's still better than being a Windows software developer [fourmilab.ch] ;)
Re:Looking at Windows NT sources (Score:1)
Re:Interesting... (Score:1)
The cost of looking at the Windows Source (Score:1)
The unofficial cost for doing so is this:
the right arm of the user in question, severed at the shoulder (heretofore referred to as "an arm"),
the left leg of the user in question, severed below the hip (heretofore referred to as "a leg"),
both visual information collection organs (VICOs, heretofore referred to as "both eyes"), extracted by means of suction,
and one membership to MSDN.
I don't think I quite trust O'Reilly's anymore. (Score:1)
wonder what it costs to look at the Windows source (Score:1)
What it costs to look at Win Source (Score:1)
Lets not forget the other costs too:
First Born
Sell soul to satan
Etc...
anything about the source management? (Score:1)
Tim
Re:This is a very good book (Score:1)
Wrong! (Score:1)
Windows Source code (Score:1)
According to posts on /.
-Your soul
-Your reputation as a REAL techie
-Unspeakable bedroom actions with Bill and friends
Re:Windows Source (Score:1)
Re:I don't think I quite trust O'Reilly's anymore. (Score:2)
Comparison of the two and other OS books (Score:2)
I own both books (and Tanenbaum's) and I have to admit that I find the BSD book most useful. I think that's because BSD was more "designed" and Linux is more a "big ball of mud" that just got to be how it is by evolution. The types of bugs I've seen over the years in Linux seem to reflect that, while the kernel and VFS design is quite clever (in an engineering sense), there are aspects pertaining to networking and filesystems (most notably) that only get addressed when they become a problem to someone who is willing to solve them (eg. Direct Server Return in 2.2.14). I'm not saying there is no design to Linux, but it is less pronounced than in *BSD. I do *NOT* think that ESR's Cathedral and Bazaar analogy is as apt as many other people seem to believe. Maybe it's just because BSD is easier to understand for me. And I work with it a lot. (and Linux... and Solaris... and NT/2K...) On the other hand, there is a much greater level of detail in Bovet and Cesati's book, line-by-line analysis of much of the kernel's data structures, which I am finding useful in hacking on it.
My bias:
I am an applications programmer, sysadmin, and network administrator, rather than a kernel developer or embedded systems programmer. So I am more interested in network and filesystem details than how certain atomic operations are implemented. I occasionally change little things here and there in the Linux kernel (almost never changing actual code semantics in any of the BSDs), but nothing earth shattering in either case. On the other hand, it is my job to *tune* kernels.
My comparison:
The Linux book seems to concentrate on internal data structures, how pieces of code are implemented, and why; more a tinkering than design perspective. The BSD book is a design-motivating-an-implementation book (as per the title). They're both useful books, but for very different reasons. At only $40, it's worth buying the Bovet and Cesati book for guidance if you hack on Linux AT ALL, especially on a laptop or a disconnected workstation (hopefully with all the HOWTOs and source installed on it!).
Is this a troll? (Score:2)
Under the hood (Score:2)
For example: let's say you have a function that gets passed a region of malloc()'ed memory. You want to know exactly how much memory you have to play with. That number is stored somewhere before the beginning of that pointer. malloc() allocates a little extra memory, writes some status info at the beginning, sticks the pointer in front of that, and returns the address to you. However, exactly where and what it writes are somewhat unspecified.
I'd love to have a function in C that did this for me, but alas, there isn't one. So what I have to do is seek back through before the pointer, hope everything is allocated, and look for something like status info. I've done this on Solaris and Linux, and they don't do it the same way.
I think stuff like this is fascinating, but using internal knowledge to write your programs can be dangerous; it must be done carefully to avoid breakage.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:1st read (Score:2)
Re:I've already taken a look at this book.. (Score:2)
If you have a form that asks for a users country, then afterwards asks for their state/province, the user-unfriendly version would simply show the same form to everyone. The user-friendly version would look at the country, and then decide (a) whether the field is needed or not, and then (b) what that field is called in that location. So, the user-friendly version is actually much, much more complex. With simple code, the user does the work, with complex code, the user gets it easy. In Linux 2.4, auto PnP support was added. That increased user-friendliness, and also greatly increased the code complexity (they had to add a whole resource-management subsystem).
Re:Looking at Windows NT sources (Score:2)
Free as in beer, maybe, but the restrictions placed on you if you take such a course can be rather onerous.
It can be rather difficult to legally find work with a Microsoft competitor, as you're "contaminated" with Microsoft IP.
Not for Microsoft programmers! (Score:2)
It is well known that this book contains fragments of code coverade under the insidious GNU Public License. If any of this code made it into our products it could force us to make the rest of the source for that product available.
We advise coders wanting to replicate the stability of LInux to look elsewhere. Reading this book can only harm your career at Microsoft!
Re:Windows Source code (Score:2)
But is it worth CowboyNeal?
Okay, I'll just be grabbing my coat . . .
Geoff
Re:I've already taken a look at this book.. (Score:2)
But in general, user friendliness is more about the graphical desktop and applications: Gnome, KDE, KOffice, StarOffice, Evolution, etc. There's a lot of differences at that level, so it would be impossible to have a single user reference for the notional "Linux User Interface". But the GUI is not strongly tied to the kernel.
I think that it should be possible to have good referenece documentation for the kernel, probably as a two volume set - one for the networking stack, and one for everything else. Just because you think the kernel is too complex to understand doesn't mean that everyone else agrees... And if we don't try to document it and understand it, we will end up in a situation where a very small number of people have the technical skills to work on the kernel, and that would be bad for the Linux community. One of the things that keeps Linux on course is that people have the option to fork it - either because they want to experiment with something, or because they have a different problem to solve (RTLinux), or they think they really can do it better than Linus. If the kernel is too hard for anyone but Linus, Alan Cox, and 30 other people in the world to understand, then that option to fork isn't really there anymore, and that would be bad for the future of Linux.
User documentation, on how to use Linux, is also important but is a completely separate issue and is probably best done by documenting distributions. Like "How To Use Red Hat 7". Of course that book doesn't need to say anything about how the kernel works - users don't care, and they shouldn't have to.
Torrey Hoffman (Azog)
Re:Windows Source code (Score:2)
--
Reviewer on Crack (Score:2)
The reviewer's second complaint is even dumber. Since the kernel is a construction based in time (rather than something more eternal), descriptions of it are going to be outdated eventually. As will any other linux book out there, when a new version gets out there. Even the New York Times will be outdated tomorrow. Big fucking deal. The authors are tracking the 2.4 changes for the next version of the book - and they plan to keep a website for the book - so everything should be okay. Plus their notes of what's new in 2.4 should be all you need for the time being.
Sorry to vent, but I hate it when reviewers feel obligated to come up with flaws, just to make it seem like they did a super-penetrating read of the text. If you want to come up with flaws, try reading the book past the introduction. I'm sure you'll find a few legitimate ones at least.
Re:Elder Tomes of Knowledge (was Re:Windows source (Score:2)
Re:Interesting... (Score:2)
Re:This is a very good book (Score:2)
Re:I've already taken a look at this book.. (Score:2)
Re:Under the hood (Score:2)
I'm curious as to why you don't allocate a whole hunk of memory and do your own memory management? Yes, it is a little bit of extra work, but that way you know *exactly* how many bytes are being used. You can do your own tagging - as little as or as much as you went/need. The modern paradigm is a "memory pool" which is quite usefull in some circumstances.
Of course if the memory is coming from outside your program, then I can see your point. Yes, I wish it was standardised too.
Data structures will NEVER be standardized across the OS's, but we CAN standardize on the API ! *wishes the proc filesystem was standard on windows, *nix, *bsd, Be, etc.
--
"Sex is like math. Divide the legs, add it in, and out comes the result." - Anonymous
NDA (Score:2)
For startes, the inability to ever code another OS again. (NDA's)
-Michael
I got this for Christmas (Score:2)
Looking at Windows NT sources (Score:2)
At my school I've seen a notice a lab course, in which the NT sources are examined and extended to support experimental services and algorithms.
Re:Comparison of the two and other OS books (Score:2)
Peter
How about a good flowcart? (Score:2)
Of course, if there is such a thing and I've overlooked it, please flame me.
Windows Source in html (Score:2)
Cheap shot...
{Body bgcolor="blue" text="white"} {center} {strong} A fatal exception error has occured in...
WTF? (Score:2)
I think I know what you were trying to say (maybe) - but Timothy, do you ever think to proof posts you read?
I just bought it... (Score:2)
I highly recommend Understanding the Linux Kernel.
--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
Re:Under the hood (Score:2)
Pass the length as another parameter. That's what fread(), sprintf(), etc mandate.
What you're talking about is home rolled resource tracking. It's not too hard to do it portably, but there are already loads of leak tracking, etc malloc() replacements out there.
Re:Looking at Windows NT sources (Score:2)
Interesting... (Score:2)
About the windows source... hhm.. there must be some internal documents explaining things, I'm guessing. Or maybe not...
Moz.
Re:1st read (Score:3)
This book is definately more of a guide, however, it is detailed enough to serve as a general reference as well. (Detailed reference == see the code
If you mean TCP/IP illustrated V.2 concerning the BSD stack implementation, then yes, this book might be slightly better from a technical prerequisite standpoint.
You will want to know some basic CPU architecture information to get the most of this book. I.e. how CPU caches work, virtual/physical address mapping, etc.
1st read (Score:3)
Seems like a sweet book, I own the BSD devil book, while ocasionally i can decypher something out of it, it ususlly makes my head spin. Does anyone know if this book is someone more geared towards a laymon, maybe a guide rather then a reference?
Also i wish they would make a book that was like a "stroll through OS design" cover the differences between OS's, what choices they made, how it effects performance, scaleability, etc.. Linux 2.2 is pretty 0ld sk00l compared to Solaris and FreeBSD.
-Jon
Streamripper [sourceforge.net]
Windows source (Score:3)
It probably costs you your sanity.
Writing Linux Device Drivers (Score:4)
This is a very good book (Score:5)
The authors layout the information they wish to present clearly, and every chapter is a refinement of these main areas of functionality.
The book is also sprinkled with a lot of code, so that you can see the concepts in action. There are also plenty of diagrams, which gives the book a feel similar to something R. Stevens would write. (like TCP/IP illustrated / Unix Network Programmin)
If this is the kind of thing your interested in, definately spin for a copy. It can be a bit hard of a read given its size and density, however worth the effort.