OSDev.org

Modern Operating Systems (which I just found at my local libary ;D) by Andrew S. Tanenbaum is great so far.

There are some real differences of opinion on these books. Design and Implementation is primarily set around the design of a specific small Unix-like OS, Minix, which was designed for the book. It gives extensive source code examples and glosses on the design decisions, and includes the full source code at the end of the book (and on the CD). However, the discussion of alternate approaches used in other OSes is limited, and it does not deal with a lot of things that are not implemented in Minix, such as spinlocks. In many ways, it's an excellent book, though Tannenbaum's English prose is often a bit unclear and meandering. One aspect of it which often confuses new students is that it does not cover the user shell in the book; the focus is entirely on the kernel and the drivers. It also does not cover the bootstrap process, except in broad terms. While this is appropriate, as neither the boot strap nor the user interface are part of the OS per se, it can be confusing.

Modern Operating Systems is split into two parts. The first part covers the same material as Design and Implementation, but uses design examples from existing systems (primarily Unix, Linux and Windows 2000) and substitutes the working Minix source with pseudocode, or eliminates it entirely. The second half covers more advanced issues of multiprocessing and distributed processing. It makes a good theoretical compelment to the more pragmatic Design and Implementation, but there is a fair amount of repetition between them. Also, the problems with understanding Tannenbaum's writing are eve more serious without the code examples to make his explanations concrete.

If you can, I would recommend looking the books up in a library first (most college libraries will have at least one of them) before you lay down all that money. Also, if you are a college student, and are thinking of taking an OS course, you might want to find out what books the courses use; you might end up using these books anyway, and may find a better deal with used copies from the university book store.

Not sure whether this is the good forum but at least the thread fits.


Does anybody know a book with a good theoretical background on fourier and cosine transforms? I've only had Algorithm Design from Baase & van Gelder and it only touches FFT (as in, how to implement it. No word on what it IS).

TIA, Candy

For anyone here that has a book store nearby selling "Linux France Magazine", go and get issue #70. It looks like David Decotigny and Thomas Petazzoni are in the middle of a collection of documents stepping through a simple operating system based on GRUB, from bootstrap to VFS ...

http://sos.enix.org/ has electronical mirror of previous articles ...

Well thats nice, a french OS

I'm thinking of buying one of these books (it sounds like I have a lot to learn!), and I've narrowed it down pretty much to "Operating Systems: Design and Implementation" by Tanenbaum, "Modern Operating Systems" by Tanenbaum, or "Operating System Concepts" by Silberschatz. I'm wondering what you guys think would be best for someone just getting into OS development. And if you know a better book than those, mention it, please.

Most of the Amazon reviews for each give the impression of a slight holy war going on.

http://www.amazon.com/...
This book must burn.

Crazed123 wrote: I'm thinking of buying one of these books (it sounds like I have a lot to learn!), and I've narrowed it down pretty much to "Operating Systems: Design and Implementation" by Tanenbaum, "Modern Operating Systems" by Tanenbaum, or "Operating System Concepts" by Silberschatz. I'm wondering what you guys think would be best for someone just getting into OS development.

don't know for "design and implementation" since i haven't read it so far, but both "MOS" and "OSC" are somehow equivalent. Pick the first one you find -- or the cheapest.

Both address similar issues and equivalent examples nowadays (linux, winNT). Maybe if you can't find one in your native language, you should prefer the english version of OSC to the english version MOS since it seems that tanenbaum's english is sometimes not as english as it should (i have read it in french, personnally, and it was quite well translated, though, so i can't really advocate for one of them).

I got MOS, and I'm hoping to be OK since I'm a native English speaker.

Now we just have to march back, hand them a receipt and demand faculty discount.

I'm pretty sure it has been mentioned earlier already, but as Pype asked for a good Assembler reference, I'll give the links (again?):

Art of Assembly (printed)

Art of Assembly (16bit DOS edition, PDF)

Art of Assembly (32bit Linux edition, PDF)

Take your pick. Not really sure which of the online editions the printed version is about, but this book covers it all. Boolean algebra, CPU architecture, cache lines, how the x86 opcodes came to pass, control structures, interrupts... you name it.

Solar wrote: Art of Assembly (printed)

Art of Assembly (16bit DOS edition, PDF)

Art of Assembly (32bit Linux edition, PDF)

Take your pick. Not really sure which of the online editions the printed version is about, but this book covers it all. Boolean algebra, CPU architecture, cache lines, how the x86 opcodes came to pass, control structures, interrupts... you name it.

Since the Art of Assembly is constantly updated & reviewed, by its author Randall Hyde (moderator of his own subforum at www.masmforum.com), he's probably best to tell about it. Short summary:

AoA DOS-version is about traditional X86. AoA Win32 version (and probably the linux version too, although I don't know for sure) talks about HLA, which is High-Level Assembler. It allows going down to asm level (the traditional opcode way) but it also allows you to program in a higher level language which maps directly on asm. Look at the book itself or at his forum for more information.

You probably want the DOS edition, even though it's counter-intuitive.

I never got the win32/linux version distinction, and apparently he doesn't either. One page (linked above) I was looking at had the win32 version for download and a link to the download page for the linux version but that download was also labelled as the win32 version :S Maybe I was just hallucinating or something

The best book ever: "The Design of the Unix Operating System", of Maurice J. Bach.

This isn't really a book, just an article I found which should be read by anyone writing any code:

The Bad Code Spotter's Guide
http://www.informit.com/articles/article.asp?p=457502

Old maps were marked with the phrase "Here be Dragons" to help seafarers steer away from dangerous places; in programming the best way to avoid dealing with bad code is to avoid writing it. Diomidis Spinellis points out 10 giveaways to spot bad code that you (or others) may have written.

Apart from number 9 about using standard libraries (not always possible for a kernel), all these things do apply to systems programming as much as applications programming.

paulbarker wrote: Apart from number 9 about using standard libraries (not always possible for a kernel), all these things do apply to systems programming as much as applications programming.

In a sense, especially number 9 applies to systems programming.

1) If you name a kernel function after a standard C function, make very sure that it behaves identically to the standard one.

2) If you create a function that is very close but not identical to a standard C function, reconsider whether it would be possible to make it identical, and cater for the small differences between the standard and your expectations elsewhere.

Both items reduce the probability of someone else being "surprised" by your code. It's OK if your kprintf() doesn't cater for floating point values because you don't use any in your kernel, but it's not OK if it turns "%%" into something else but "%", does support "%d" but not "%i", automatically adds a '\n' at the end, or doesn't return an int. If you insist on doing it differently, don't call the function kprintf() but something else, and if at all possible, make it consistent with whatever user-space API you provide for formatted output.

Same for kmalloc() - if you make it accept more than a single parameter, or return something different from the standard, call it something else, because people see "(k)malloc" and expect it to behave in a certain way.