

Roll your own toy UNIX-clone OS - Rusky
http://www.jamesmolloy.co.uk/tutorial_html/index.html

======
jwatzman
Stylistically, there are a huge number of things wrong with this. The idea is
good, but if you actually write code this way you'll have a slow,
unmaintainable mess of a kernel.

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.

~~~
Sapient
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.

~~~
mahmud
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".

------
tseabrooks
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.

~~~
derleth
> 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.)

~~~
mfukar
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.

~~~
derleth
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://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th_Edition,_with_Source_Code)

<http://www.freebsd.org/doc/en/books/design-44bsd/>

~~~
mfukar
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.

~~~
derleth
> nor obsolete

Minix is so different from most OSes in use that this doesn't even make sense.

~~~
mfukar
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.

~~~
derleth
> 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.

------
wigginus
Previous discussion: <http://news.ycombinator.com/item?id=418329>

------
ghotli
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/>

------
danieldk
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.

------
jacquesm
ranking bug: why is a 'dead' spam comment ranked higher than a 5 upvote
comment?

