5 ms·

Roll your own toy UNIX-clone OS

109 points by Rusky 16y ago

deleted 16y ago
[deleted]
deleted 16y ago
[deleted]
wigginus 16y ago
Previous discussion: http://news.ycombinator.com/item?id=418329 http://news.ycombinator.com/item?id=418329
ghkluifge 16y ago
●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● Gold autumn, personality Mes clothing + Shoes, Travel bag that grabs an eye coat + Chao packet Free transport ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------●
jacquesm 16y ago
ranking bug: why is a 'dead' spam comment ranked higher than a 5 upvote comment?
danieldk 16y ago
OSKit used to be the nicest way to roll your own UNIX: http://www.cs.utah.edu/flux/oskit/ http://www.cs.utah.edu/flux/oskit/ Unfortunately, the project seems to be dead.
tseabrooks 16y ago
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 16y ago
  > 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 16y ago
    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 16y ago
      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_Edition,_with_Source_Code http://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th... http://www.freebsd.org/doc/en/books/design-44bsd/ http://www.freebsd.org/doc/en/books/design-44bsd/
      - mfukar 16y ago
        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.
ghotli 16y ago
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/ http://www.linuxfromscratch.org/
jwatzman 16y ago
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 16y ago
  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 16y ago
    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".
- Rusky 16y ago
  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.

109 points by Rusky 16y ago

deleted 16y ago

[deleted]

deleted 16y ago

[deleted]

wigginus 16y ago

Previous discussion: http://news.ycombinator.com/item?id=418329 http://news.ycombinator.com/item?id=418329

ghkluifge 16y ago

●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● Gold autumn, personality Mes clothing + Shoes, Travel bag that grabs an eye coat + Chao packet Free transport ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------● ●------ http://u.ly/73I http://u.ly/73I ------●

jacquesm 16y ago

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

danieldk 16y ago

OSKit used to be the nicest way to roll your own UNIX: http://www.cs.utah.edu/flux/oskit/ http://www.cs.utah.edu/flux/oskit/ Unfortunately, the project seems to be dead.

tseabrooks 16y ago

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 16y ago
> 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 16y ago
  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 16y ago
    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_Edition,_with_Source_Code http://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th... http://www.freebsd.org/doc/en/books/design-44bsd/ http://www.freebsd.org/doc/en/books/design-44bsd/
    - mfukar 16y ago
      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.

ghotli 16y ago

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/ http://www.linuxfromscratch.org/

jwatzman 16y ago

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 16y ago
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 16y ago
  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".
Rusky 16y ago
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.