程序天空

Don't get scared or distracted

Paraphrasing our friend Mr. Brooks Jr. a third time, the process of creation goes in three steps. First the idea, when you have an ideal representation in your mind of your project, and it sounds all perfect. Then comes the implementation, where you face the limitations of the physical medium, and try to get it to work. This is where the flaws in your idea appear, and have to be fixed before you have something that works. Lastly is the interaction, where you get feedback from users.

The idea is always the fun stage. When you start implementing it, you get frustrated by slow progress and limitations of the hardware interfaces that don't exactly map to your concepts. The temptation to jump to another project in "idea" stage is very high. I've been there.

You have to get confident that your project is great and that it will work out. A new project being more fun is just an illusion. Once you move to implementation stage, it will be just the same as your OS. Stick with it. Don't get distracted by something else unless you are certain you want to give up on the OS project because you don't think it is useful anymore, and not because working on something else is more interesting.

Don't get scared by other projects. You see somebody coming up with a similar idea. So what. They, too, have to implement it. Only match your work against other existing work, not some idea-stage project. Stay confident.

Don't get sidetracked. Out of the hundreds of projects online, there is a preposterous amount that is also working on a GUI. A text editor. A SETI client. Whatever it is. Stick to the kernel. It is a lot more realistic that you can come up with a better, or at least, working, kernel, than it is to come up with a kernel, a GUI, a TCP/IP stack and accounting software, starting all from scratch. Unless you have an overriding reason, such as rewriting a whole system in Forth, or using an entirely new way of designing software that allows for no recycling, refrain from it.

The most compelling reason not to develop a GUI on top of your kernel is to show how useful or useless your kernel is. If you write all the software that runs on your system, you set all rules of the game, and never get a chance to see if your code actually fulfills the requirements. Porting and running existing applications or GUIs is a great test of your kernel interface. You will have to match it with real-world requirements. If you can't, you're in trouble.

Form is liberating

Free software projects have a lot less constraints than commercial software. The code ships "when it is ready", not before. This gives time to perfect the code until it is well structured and reliable.

Constraints are not entirely bad. Limitations in hardware, budget, memory, time, and other software APIs are great to resolve endless discussions and spot inconsistent design. Constraints force you to take decisions and cut an endless debate. Not having any direction encourages sloth, argumentation and not taking decisions at all.

This is why I would advocate that if you have no particular plans other than writing your own operating system, you should clone an existing design and not try to improve it until you have a version that works. Linux is obviously a good example of that.

Another real-world example is AROS, the Amiga Research Operating System. The project history teaches us that they originally tried to design a better AmigaOS than AmigaOS, adding virtual memory and all sorts of features people had been longing for in the original environment. After endless debates about how to implement them, somebody took over and decided to clone the original, call by call, and then see about the improvements. Suddenly the project started and has been making great progress since then.

Bottom-up and top-down approaches

From experience, coming up with a working kernel, excluding any considerations of new architecture or design, can be broken up into a few stages:

1. Boot an image written in a high-level language
2. Boot it with paging, if desired
3. Write basic drivers for debug and communication with host.
4. Add memory management. Write test-suite. Debug.
5. Write basic drivers for timers. Write test-suite. Debug.
6. Add multitasking. Write test-suite. Debug.
7. Add and extend drivers and a file system. Write test-suite. Debug.
8. Run a simple user program. Debug all side effects that this brings up.
9. Run a simple command interpreter.
10. Run simple applications from the interpreter. Debug side effects.
11. Port and run existing applications of increasing complexity. Major debugging.
12. Port the whole thing to other architectures. Repeat steps 1-3 and 5 and more major debugging.

If your system is carefully designed, steps 4 to 11 can partly or entirely be completed on top of another operating system. To some extent, in reverse order. This is the top-down approach. I would highly recommend it if you don't feel comfortable with climbing Mount Everest in shorts with a single bottle of water.

The bottom-up approach is to start with the boot loader and complete steps in the order described above. This obviously has been done before, but again, at the risk of hammering you over the head with it, is a lot more complex.

The latter approach can be made easier. First, writing your system for x86, unless you absolutely want to write your own umpteenth incompatible boot loader and protected mode jump code, a standard, dependable boot loader such as Grub will make it a lot less painful to complete a very important milestone: booting code in a high-level language on the target, in a packaged and controlled bootable image.

You can also use OSKit to avoid having to write most of your kernel before it can say "hello world" from a user space application. Unlike completing the steps on top of another operating system, you can gradually replace code by your own.

A fellow programmer suggested another smart approach. Use a simple, interactive and mono-tasking OS, which will give you access to the machine while providing an interactive environment with a file system and whatnot. Namely DOS: you can start the kernel on top of a running system, take over interrupts and memory management, use the underlying system for all sorts of things, and even exit to it if needed.

Conclusion

This covers mentally bootstrapping your kernel coding process in more detail. This does not even begin to discuss how to steer your project and never lose sight of your end goal, once you got it started. This will be the subject of another article.