Steps for writing an operating system
5 comments
Well there is the Minix which is a Unix like os that predates and inspired Linux which exists purely to teach operating system design and coding.
http://www.minix3.org/
Source code included :)
http://www.minix3.org/
Source code included :)
Thanks for the suggestion, I have started studying Minix.
Disclaimer: I'm by no means an operating systems expert. I am simply a computer engineering student who has recently written my own OS, from scratch.
First things first, limit your scope! All of those links seem to want to tell you how to write an OS to run on a standard PC. That is going to be a huge nightmare. Presumably, you'll want to be able to access some (or all) of the peripherals on your PC, so you'll have to write drivers for them, which is incredibly time-consuming and error-prone. Instead, write for a smaller platform with simple peripherals. Something like a Gumstix, or ARM development board. You should be able to easily get documentation for each hardware component.
Second, don't try to mimic Linux. It may seem appealing because Linux is great, but its underlying architecture isn't. Linux has a monolithic kernel, meaning that there is a lot of functionality in there. If your display code gets into a bad state, it can bring the entire system down. It's also not very fun to manage the interface when you have 250+ system calls.
Instead of a monolithic kernel, use a microkernel structure. In a microkernel, you essentially have basic scheduling, inter-process communication, and memory management. Everything else lives outside of the kernel in separate processes, which communicate via message passing. This makes it much more stable, since there's a smaller chance of the entire system being taken down. It's also a lot easier to have your OS certified (essential if you want to use it in industrial or safety-critical scenarios) when it's broken down into small pieces.
Third, you'll have to read up on scheduling algorithms, context switching (this will require knowledge of assembly for your chosen platform), memory management and concurrency. Those are just the bare minimum for a working OS!
Fourth, get some partners for your project. Writing an OS is a lot of work, and your friends will help to encourage you. They'll also help to prevent you from making silly design decisions.
Good luck!
First things first, limit your scope! All of those links seem to want to tell you how to write an OS to run on a standard PC. That is going to be a huge nightmare. Presumably, you'll want to be able to access some (or all) of the peripherals on your PC, so you'll have to write drivers for them, which is incredibly time-consuming and error-prone. Instead, write for a smaller platform with simple peripherals. Something like a Gumstix, or ARM development board. You should be able to easily get documentation for each hardware component.
Second, don't try to mimic Linux. It may seem appealing because Linux is great, but its underlying architecture isn't. Linux has a monolithic kernel, meaning that there is a lot of functionality in there. If your display code gets into a bad state, it can bring the entire system down. It's also not very fun to manage the interface when you have 250+ system calls.
Instead of a monolithic kernel, use a microkernel structure. In a microkernel, you essentially have basic scheduling, inter-process communication, and memory management. Everything else lives outside of the kernel in separate processes, which communicate via message passing. This makes it much more stable, since there's a smaller chance of the entire system being taken down. It's also a lot easier to have your OS certified (essential if you want to use it in industrial or safety-critical scenarios) when it's broken down into small pieces.
Third, you'll have to read up on scheduling algorithms, context switching (this will require knowledge of assembly for your chosen platform), memory management and concurrency. Those are just the bare minimum for a working OS!
Fourth, get some partners for your project. Writing an OS is a lot of work, and your friends will help to encourage you. They'll also help to prevent you from making silly design decisions.
Good luck!
Thanks for informing me regarding the monolithic kernel of linux. By the way, I ve already studied the topics like scheduling algorithms, context switching, memory management and concurrency during my MCA, but you know colleges in India do not impart much of the practical knowledge. I think a Minix system with a microkernel will be great to start with.
Thanks again!!
Thanks again!!
There is an old(er) book called "Developing Your Own 32-Bit Operating System" that does a good job (assuming you're targeting the x86 platform) of laying the foundation and explaining the typical layers of code you'll need to write to build an O/S from scratch (as opposed to just a new Linux distro, etc.).
It's a bit dated, but so is the x86 platform :) I think most of it is relevant, especially someone asking these sorts of questions about OS development.
Here's a link to the book on Amazon:
http://www.amazon.com/Developing-32-Bit-Operating-System-Cd-...
If you get somewhere be sure to update us on your progress!
It's a bit dated, but so is the x86 platform :) I think most of it is relevant, especially someone asking these sorts of questions about OS development.
Here's a link to the book on Amazon:
http://www.amazon.com/Developing-32-Bit-Operating-System-Cd-...
If you get somewhere be sure to update us on your progress!
I have used this book. It's a good introduction but uses a rather non-*nix sysAPI. I have found Minix to be a better way to get started and it too has a great book as well as significant number of sites that have excellent additional material. Haiku is a very cool OS that is very clean and in early stages of development. Plan9, Inferno and L4 (Pistachio) have their strengths.
If your goal is to learn about OS design, etc then you might want to look at some CS texts that go into lots of detail. The key thing to remember is that most OS concepts (but not the implementations) have matured.
You'd probably learn more by implementing some missing functionality in an existing OSS OS.
Regardless of what you decide to do, I do recommend using QEMU as your development environment rather than running development versions on bare hardware. What I like about QEMU is that it supports ARM, etc. So as other respondents have pointed out, you would be targeting a far cleaner platform than your PC based system with three decades of backward compatability crud.
If your goal is to learn about OS design, etc then you might want to look at some CS texts that go into lots of detail. The key thing to remember is that most OS concepts (but not the implementations) have matured.
You'd probably learn more by implementing some missing functionality in an existing OSS OS.
Regardless of what you decide to do, I do recommend using QEMU as your development environment rather than running development versions on bare hardware. What I like about QEMU is that it supports ARM, etc. So as other respondents have pointed out, you would be targeting a far cleaner platform than your PC based system with three decades of backward compatability crud.
"I have used this book. It's a good introduction but uses a rather non-nix sysAPI"*
I think the only reason this would be a down-side would be if you were trying to implement a unix-like operating system (not that there's anything wrong with that).
It would do up-and-coming designers good to avoid Unix only because it's becoming sort of a "standard" way of architecting an OS and studying only unix-like systems can have an effect on creativity, innovation, etc.
I love BeOS/Haiku but even it is a bit too "unixy" for my taste.
I definitely agree with the previous post that going back to CS texts is the way to go, and it would be instructive to look at the operating systems once used by mainframes in the past as this is where allot of the "contemporary" technology we use today came from.
Ultimately the goals you have for the system you are designing should drive your architecture but I think a rich diet of various different operating systems is a good way to prepare for the journey.
I think the only reason this would be a down-side would be if you were trying to implement a unix-like operating system (not that there's anything wrong with that).
It would do up-and-coming designers good to avoid Unix only because it's becoming sort of a "standard" way of architecting an OS and studying only unix-like systems can have an effect on creativity, innovation, etc.
I love BeOS/Haiku but even it is a bit too "unixy" for my taste.
I definitely agree with the previous post that going back to CS texts is the way to go, and it would be instructive to look at the operating systems once used by mainframes in the past as this is where allot of the "contemporary" technology we use today came from.
Ultimately the goals you have for the system you are designing should drive your architecture but I think a rich diet of various different operating systems is a good way to prepare for the journey.
Thanks for your valuable time but i have not come accross topics like QEMU and ARM. As soons as I study them ?I'll get get back to you !!
thanks again !!
thanks again !!
I have downloaded the book as per your suggestion, and I have skimmed through it, As soon as I will start some code writing I'll inform you regarding my progress,
Thanks a lot !!
Thanks a lot !!
[deleted]
dear friends,
On the basis of your suggestions, Ive concluded the following: 1. Studying Minix as an operating system will be a great deal as its source code is just around 4000 lines. 2. Minix being a micro-kernel based OS will be easier to tackle. 3. The OS book written by tennanbaum with respect to Minix [describing each aspect of Minix along with source code] is available to us. 4. Though Minix is immature yet, it will help us to get started at least. 5. The book on the link 'http://www.amazon.com/Developing-32-Bit-Operating-System-Cd- is bound to be a great deal of help [I skimmed through it yesterday]
I shall come back to you again if I run into trouble again Thanks for your valuable time.
On the basis of your suggestions, Ive concluded the following: 1. Studying Minix as an operating system will be a great deal as its source code is just around 4000 lines. 2. Minix being a micro-kernel based OS will be easier to tackle. 3. The OS book written by tennanbaum with respect to Minix [describing each aspect of Minix along with source code] is available to us. 4. Though Minix is immature yet, it will help us to get started at least. 5. The book on the link 'http://www.amazon.com/Developing-32-Bit-Operating-System-Cd- is bound to be a great deal of help [I skimmed through it yesterday]
I shall come back to you again if I run into trouble again Thanks for your valuable time.
http://www.linuxfromscratch.org/lfs/index.html http://www.linuxfromscratch.org/lfs/view/6.5/
http://www.acm.uiuc.edu/sigops/roll_your_own/ http://www.brokenthorn.com/Resources/OSDevIndex.html
I just wanted a list of steps written in plain english, to be followed for writing an operating system, then one by one i can do self-research on each one of them, I am an efficient c/c++ programmer, but i just don't know where to begin writing an os,
kindly help !!