Roll your own toy UNIX-clone OS(jamesmolloy.co.uk)
jamesmolloy.co.uk
Roll your own toy UNIX-clone OS
http://www.jamesmolloy.co.uk/tutorial_html/index.html
9 comments
Hi,
I know, there are some seriously bad stylistic mistakes in that code, as well as doing some things "the wrong way" (stack move instead of a recursive page directory is a prime example).
The tutorial series was written in 2007, so quite a time ago. I got around to rewriting the code, but not the overlaying documentation and explanation so the old version is still live.
New version for anyone that cares: http://jamesm-tutorials.googlecode.com/ . Much better stylistically, and with sound practices throughout.
It should also be noted that my tutorial series was not designed to teach people "how to write a kernel" - more to show how to bridge the gap between theory and practice. There are many books and resources (Tanenbaum's book is an example) that deals purely with theory - algorithms used etc.
There are also many resources about assembler programming and C, but to my knowledge not really many that showed how to apply the theory, concrete it and end up with "something" that runs (which can then ideally be adapted based on better theory).
I know, there are some seriously bad stylistic mistakes in that code, as well as doing some things "the wrong way" (stack move instead of a recursive page directory is a prime example).
The tutorial series was written in 2007, so quite a time ago. I got around to rewriting the code, but not the overlaying documentation and explanation so the old version is still live.
New version for anyone that cares: http://jamesm-tutorials.googlecode.com/ . Much better stylistically, and with sound practices throughout.
It should also be noted that my tutorial series was not designed to teach people "how to write a kernel" - more to show how to bridge the gap between theory and practice. There are many books and resources (Tanenbaum's book is an example) that deals purely with theory - algorithms used etc.
There are also many resources about assembler programming and C, but to my knowledge not really many that showed how to apply the theory, concrete it and end up with "something" that runs (which can then ideally be adapted based on better theory).
Do you know of anything we can have a look at which gives a better overview of kernel architecture?
I am really more interested in learning more about good kernel architecture and rolling one the "Right Way" than I am in getting a working but crappy kernel.
I am really more interested in learning more about good kernel architecture and rolling one the "Right Way" than I am in getting a working but crappy kernel.
It's a C issue, not an implementation issue. Learn C well.
Alternatively, study OS kernels not implemented in C. It's all basic algorithms and can be implemented in any language, if you content with abstraction and don't mind working with emulated "devices".
Alternatively, study OS kernels not implemented in C. It's all basic algorithms and can be implemented in any language, if you content with abstraction and don't mind working with emulated "devices".
While the example code is horrible in many ways, this is the best tutorial I've seen theory-wise (although that's not counting the Minix book since I haven't been able to read that yet).
If you have any experience programming in C, which you should if you're attempting this, the horribleness is somewhat forgivable, and it's a good experience trying to write it on a nicer way, debugging your own kernel code, etc.
If you have any experience programming in C, which you should if you're attempting this, the horribleness is somewhat forgivable, and it's a good experience trying to write it on a nicer way, debugging your own kernel code, etc.
My Op Sys class in school was designed around compiling your own toy 'unix' kernel and rewriting large portions of it from scratch for educational reasons. We used the Tanenbaum book and his "Minix" system. It was far and away the most informative class I had in school.
> We used the Tanenbaum book and his "Minix" system.
The 'problem' with this, if you want to approach it that way, is that Minix is not representative of how most OSes in the real world work: It's a microkernel in a world of monolithic kernels, which means studying it to learn how the rest of the OS world works is a bit like looking at electric engines to figure out how your gas-powered car runs on the inside.
(There's also the jibe that microkernels are the wave of the future, and always will be.)
The 'problem' with this, if you want to approach it that way, is that Minix is not representative of how most OSes in the real world work: It's a microkernel in a world of monolithic kernels, which means studying it to learn how the rest of the OS world works is a bit like looking at electric engines to figure out how your gas-powered car runs on the inside.
(There's also the jibe that microkernels are the wave of the future, and always will be.)
The architecture really doesn't matter, in the context of a course. Understanding concepts like scheduling, filesystems, mm etc. and perhaps tinkering with a reference implementation is more rewarding for beginners, and Minix is simple enough to allow a CS undergrad to get involved rather quickly.
So, if the architecture really doesn't matter, why not use the Lions' book and teach Sixth Edition Unix, or use "The Design and Implementation of the 4.4BSD Operating System"? Is it a holdover from the 1980s, when microkernels were still interesting, or is it because Tanenbaum is seen as a 'real' academic?
http://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th...
http://www.freebsd.org/doc/en/books/design-44bsd/
http://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th...
http://www.freebsd.org/doc/en/books/design-44bsd/
Because Minix is neither overly complex, nor obsolete. It nears the sweet spot between simplicity and functionality - I don't know how much of that I can attribute to its architecture. I don't think it has anything to do with academic credibility or holding grudges.
That's my opinion, of course, and perhaps my CS professors stuck to Tanenbaum religiously.
That's my opinion, of course, and perhaps my CS professors stuck to Tanenbaum religiously.
> nor obsolete
Minix is so different from most OSes in use that this doesn't even make sense.
Minix is so different from most OSes in use that this doesn't even make sense.
While Minix, like dozens of OSs, is far from having a measurable market share - especially compared to Linux/Windows/BSD/etc - is also far from being either unwanted or disused. It's actively developed and promoted. Why would you characterize it obsolete based on its difference from "mainstream" OSs? That doesn't make sense.
> Why would you characterize it obsolete based on its difference from "mainstream" OSs?
I didn't. I explicitly said that the concept of 'obsolete' doesn't apply to it, because it's so different from everything else.
I didn't. I explicitly said that the concept of 'obsolete' doesn't apply to it, because it's so different from everything else.
Previous discussion: http://news.ycombinator.com/item?id=418329
The step up from this is Linux From Scratch. As a teenager, starting with a host os and loading the individual pieces of a functional linux distribution taught me a skill that has turned out to be very valuable.
Whereas the link above will help you learn the innards of a kernel, this will help you understand what packages on top of that make a functional, useful system.
http://www.linuxfromscratch.org/
Whereas the link above will help you learn the innards of a kernel, this will help you understand what packages on top of that make a functional, useful system.
http://www.linuxfromscratch.org/
[deleted]
OSKit used to be the nicest way to roll your own UNIX:
http://www.cs.utah.edu/flux/oskit/
Unfortunately, the project seems to be dead.
Unfortunately, the project seems to be dead.
[deleted]
ranking bug: why is a 'dead' spam comment ranked higher than a 5 upvote comment?
The biggest issues that jump out at me are the horrible overuse of magic numbers (#define is your friend, especially when working with the GDT and IDT) and the disabling of interrupts and paging when copying an address space (the latter of which is slow and the former of which prevents concurrency -- imagine how well Linux would work if every fork() were terribly slow and stopped the world -- doing this in even a halfway reasonable way is not hard). Inline assembly is also a really bad idea for portability and maintainability, the latter of which you at least care about for a toy kernel. I'm also not sure why they are disabling interrupts so much in general... and on and on.
Again, a very interesting read for kernel-development-n00bs, I'm sure, but a lot of their code is very, very, terrifyingly wrong even for a toy kernel. Our OS class has students write a kernel somewhat like this one; the class provides a list of things which you are not to ever do, ever, oh god, or you will fail. This article does a staggering number of those things.