I'm a very ambitious university student who wishes to learn pretty much everything there is to know about computers (bash me if you want, I love learning). Recently I thought it would be a fun project (albeit a lengthy one) to design and build my own kernel.

I got some basic info and I've gathered that I need to master Assembly and C/C++ to really make this work. While I'm working on those, I'd like to learn HOW a kernel actually works from a programming perspective. I've spent hours browsing the linux kernel's code but that can only take you so far.

What are the basic steps in building a kernel? Things you need to address? Order or doing things? I know I'm biting off a lot but I'm determined enough to handle it.

closed as too broad by user40980, Kilian Foth, gnat, Bart van Ingen Schenau, GlenH7 May 12 '14 at 13:54

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 12
    No need to bash you for wanting to learn everything. But if you plan on actually trying to, you better have extended lifespan, a superhuman brain and no other plans for your life ;) – user7043 Jun 16 '11 at 17:29
  • 2
    I expect to have all of those! Not really though, I just have an overwhelming urge to learn. – n0pe Jun 16 '11 at 17:30
  • @delnan Possible paranoid schizophrenia is a plus too: templeos.org – DanteTheEgregore Oct 4 '13 at 16:16
  • @DanteTheEgregore What the? – Panzercrisis Mar 12 '15 at 17:56

What you need to do is design the operating system. Even if, for example, you decide it should be a UNIX-like system, there are still lots of decisions to make. How much like UNIX do you want it to be? Which parts of UNIX do you like and which do you think need improvement?

If you aren't set on its being UNIX-like, you end up with even more questions to answer: should processes form a tree, or are they "flat"? What kinds of inter-process communication do you want to support? Do you want it to be multi-user, or just multi-tasking (or possibly single-tasking)? Do you want it to be a real-time system? What degree of isolation do you want to provide between tasks? Where do you want it to fall on the monolithic vs. micro-kernel scale? To what degree (if any) do you want it to support distributed operation?

I'd generally advise against studying the Linux kernel for your inspiration. That's nothing against the Linux kernel itself, but a simple fact that Linux is intended primarily for production use, not education. It has lots of optimization, backward compatibility hacks, etc., that are extremely useful for production but more likely to distract than educate.

If you can find it, a copy of Lion's book (Lions' Commentary on UNIX 6th Edition, with Source Code, by John Lions) is a much easier starting point. 6th Edition UNIX was still small and simple enough to read and understand fairly quickly, without being an oversimplified toy system.

If you're planning to target the x86 (at least primarily) you might also want to look at MMURTL V 1.0 by Richard Burgess. This presents a system for the x86 that uses the x86 hardware much more as the CPU designers originally intended -- something most real systems eschew in favor of portability to other CPUs. As you might guess, this tends to be oriented much more heavily toward the hardware end of things. Printed copies seem to be expensive and hard to find, but you can download the text and code for free.

Fortunately, there are quite a few more possibilities as well -- Operating System Design and Implementation, by Andrew Tanenbaum and Albert Woodhull, for example.

  • Wow thanks for the nice response. I'll look into all those books. – n0pe Jun 16 '11 at 17:46
  • 7
    I added links to PDFs of the book and source. The amazing thing about the source for v6 UNIX is that it is 100 pages long, with 100 lines per page. And in 10,000 lines of code you have a complete, multitasking operating system. If you can truly understand the code surrounding the famous comment at line 2238, "You are not expected to understand this," you can give yourself a Gold Star and an Honorary Masters. Enjoy! – Peter Rowell Jun 16 '11 at 17:54
  • Thanks for the links! Now I have to figure out where to print this.... – n0pe Jun 16 '11 at 18:03
  • 1
    Minix (the Tannenbaum book) is designed for education and may be just what is needed here. – user1249 Jan 30 '12 at 10:59
  • @PeterRowell, dmr stated it was a bug in cm.bell-labs.com/who/dmr/odd.html – user1249 Jan 30 '12 at 11:01

I'd suggest starting with a tiny, highly focused task: using assembly, write a toy bootstrap program. It doesn't have to do much. You just want the computer to automatically load the program when it starts up, print a message confirming that it is running, read some input form the keyboard, print another message, and then shut down the computer.

This would have several benefits:

  1. You are eventually going to need a bootstrap process for your kernel, so it's not going to be a pointless exercise.
  2. It will give you practice in writing in assembly.
  3. It will give your practice in writing low-level IO routines. How do you write a message to the screen, or read a keystroke when there is no OS for you to call on?
  4. It will give you experience doing research on the technical minutiae of the CPU and the mother board. (First question: how does your motherboard/cpu find a bootable program when it starts?)
  5. Writing kernels has become a very sophisticated task, with a ton of subtleties. This task will give you something to start with and maybe keep you from getting lost in the weeds before you even begin.

Once you can do this, you'll have a much better idea of what you are getting into.

  • Thanks for this, I think this is exactly what I'm going to try and do. More reading in my future. – n0pe Jun 16 '11 at 18:26

Learning how to program in assembler is a good first start and doing it from MSDOS 6.0 might be helpful as well due to a lack of built in features.

Reading a good book like Operating System Concepts would be a fair start to designing your own kernel. You'll have to handle boot loading, device driver management, interfacing with BIOS, file system creation and management, program scheduling, program loading and unloading, implement at least some sort of shell (much easier then building a windowing system).

C/C++ are only going to work if your kernel is compatible with the standard libraries for these languages, else wise you'll need to write a copy of these libraries as well.

That's not even beginning to think about multithreading, system security, networking.


Minix is a nice Unix clone (which inspired Linux) which was written for teaching.

Andrew S. Tannenbaum is an excellent writer and teacher and has written a whole book about operating systems using Minix as the example (and includes the source code to follow along): http://en.wikipedia.org/wiki/Operating_Systems:_Design_and_Implementation

Personally I find he is somewhat a better writer than programmer so some things are not as clear as I would personally like, but - hey - it works!

I can strongly recommend looking into this as a learning resource. It will also give you an idea of the amount of work needed to actually produce something which can actually be useful.

  • I'd recommend getting the physical book. Easier to take notes in. – user1249 Jun 17 '11 at 14:29
  • Actually come to think of it, I think I saw the book on Amazon for cheap. I might get it there. Thanks – n0pe Jun 17 '11 at 14:40
  • Also note that this is third edition. I believe we used the first edition back when I had the course. – user1249 Jun 17 '11 at 14:44

I've been learning it as well. You can check out these resources. They're very good!



Have fun along the way!

Not the answer you're looking for? Browse other questions tagged or ask your own question.