Writing a simple operating system from scratch (2010) [pdf]
cs.bham.ac.uk
cs.bham.ac.uk
It's been a few years since I took the class but it was an absolute blast. The offering in 2011 has recorded lecture videos (http://pdos.csail.mit.edu/6.828/2011/schedule.html).
Have you done any work in a related project after taking this course?
Yes if only MIT spent some money and made high quality videos available for free to millions of people...
I enjoy going to http://wiki.osdev.org for a broad overview and then hitting the manuals for the details; sometimes that manual and note book session can take up to 3 days of my free time haha.
I especially love writing custom tools around the development process; I like to call it reducing reliance - I found that this really helps solidify concepts in my mind; although making the process even slower, I feel comfortable at every stage.
(alert: it's not really a book, it's a project: to compile and install linux without using any distro! the whole process could take somewhere from 1 day to 1 week, depending on the speed of your machine and your command-line skills.)
Because then you would discover (if you haven't already) that what all these people call "operating system" is essentially only a nucleus of the operating system (kernel) and that there is much more to an operating system than whatever is discussed in an OS class.
Also LFS is enlightening in ways I may not have expressed here. If you successfully go through the process, your first thought might be to roll your own linux distro!
Some pointers: http://www.landley.net/ols/ols2007/tutorial.txt, found via https://encrypted.google.com/search?hl=en&q=linuxfromscratch...
Better pointers: http://landley.net/aboriginal/about.html via more googling: https://encrypted.google.com/search?hl=en&q=minimal%20self%2...
Nowadays, the most useful 'self-building' OS/bin stack is debian with build-essentials.
Don't.
I developed a from-scratch operating system as part of my PhD thesis. We initially ran it on qemu due to its speed and simplicity, but the truth is that while qemu would run something developed on real hardware, it would also run a lot more. What it accepted was very, very loose and when you developed for qemu, you generally couldn't take it and run it on real hardware without days worth of debugging and trying to figure out where qemu did things just a little more loosely than actual hardware did.
We ended up using Bochs for that purpose, which is a lot slower but a lot more faithful (and unfortunately lacks a lot of secondary hardware that's important, but it will take you a long time in development before you hit that particular limitation).
(from http://www.cs.cmu.edu/~awb/linux.history.html)
(he would have hated the machines I use these days, they take 6 minutes to boot)
"The worst part is starting off: after you have even a minimal system you can use printf etc, but moving to protected mode on a 386 isn't fun, especially if you at first don't know the architecture very well. It's distressingly easy to reboot the system at this stage: if the 386 notices something is wrong, it shuts down and reboots - you don't even get a chance to see what's wrong.
Printf() isn't very useful - a reboot also clears the screen, and anyway, you have to have access to video-mem, which might fail if your segments are incorrect etc. Don't even think about debuggers: no debugger I know of can follow a 386 into protected mode. A 386 emulator might do the job, or some heavy hardware, but that isn't usually feasible.
What I used was a simple killing-loop: I put in statements like
die: jmp die
at strategic places. If it locked up, you were ok, if it rebooted, you knew at least it happened before the die-loop. Alternatively, you might use the sound io ports for some sound-clues, but as I had no experience with PC hardware, I didn't even use that. I'm not saying this is the only way: I didn't start off to write a kernel, I just wanted to explore the 386 task-switching primitives etc, and that's how I started off (in about April-91).
After you have a minimal system up and can use the screen for output, it gets a bit easier, but that's when you have to enable interrupts. Bang, instant reboot, and back to the old way. All in all, it took about 2 months for me to get all the 386 things pretty well sorted out so that I no longer had to count on avoiding rebooting at once, and having the basic things set up (paging, timer-interrupt and a simple task-switcher to test out the segments etc)."
http://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.ht...
So you could have your own graphical workstation. :)
Nickolai Zeldovich a current MIT professor wrote HiStar OS from scratch and it's source is still available online to view how a minimally trusted system could work http://www.scs.stanford.edu/histar/
http://www.sal.ksu.edu/faculty/tim/ossg/index.html
http://www.csi.ucd.ie/staff/jcarthy/home/alp/alp-05.pdf
http://www.superfrink.net/athenaeum/
http://www.cs.utah.edu/flux/oskit/html/oskit-www.html
http://duartes.org/gustavo/blog/post/how-computers-boot-up/
http://duartes.org/gustavo/blog/post/kernel-boot-process/
http://www.ibm.com/developerworks/library/l-linuxboot/index....
http://www.osdever.net/bkerndev/Docs/title.htm
http://sourceforge.net/p/oszur11/code/ci/master/tree/
http://www.codeproject.com/Articles/737545/Writing-a-bit-dum...
http://freevideolectures.com/Course/2653/CSE-30341-Operating...
I would also recommend Andrew Tanenbaum's "Modern Operating Systems" or "Operating Systems: Design and Implementation" (the MINIX book), to anyone interested in OS dev. I read it when I was teenager (around 15), and I really really enjoyed it. Tanenbaums' books were one of the few truly addicting textbooks. As a side, "Structured Computer Organization" by Tanenbaum was also really great. It gives you a foundational understanding of how computers are architected that is indispensable if you're going to be doing OS dev.
That document inspired me to create a Github repo with only the code, split into micro lessons. Feel free to check it out, I'll update it at the same pace that I process the document and learn stuff myself https://github.com/cfenollosa/os-tutorial
(http://www.amazon.com/Peter-Nortons-Assembly-Language-Book/d...)
Do you have any recommendations?
Though ultimately I have no plans to get into the kernel space for development.
http://www.cs.bham.ac.uk/~exr/lectures/opsys/13_14/lectures....
> qemu
Don't.
I developed a from-scratch operating system as part of my PhD thesis. We initially ran it on qemu due to its speed and simplicity, but the truth is that while qemu would run something developed for real hardware, it would also run a lot more. What it accepted was very, very loose and when you developed for qemu, you generally couldn't take it and run it on real hardware without days worth of debugging and trying to figure out where qemu did things just a little more loosely than actual hardware did.
We ended up using Bochs for that purpose, which is a lot slower but a lot more faithful (and unfortunately lacks a lot of secondary hardware that's important, but it will take you a long time in development before you hit that particular limitation).