History of XOmB
XOmB has a long and colorful history. This is a living document discussing said past.
XOmB originally came about as a joke. Our group wanted to learn the D Programming Language, and so we decided to do a project together. While discussing what kind of project we should undertake, someone suggested an operating system. We then had several discussions about how we would implement it, if we would actually go through with it, and realized that we had several interesting ideas.
The Early Days
Once the design was agreed upon, we started to actually lay down the code. Everything was stubbed out, nothing worked, but the project was on its way! A small subset of the runtime was usable and a simple implementation executed (entirely in privileged 64 bit mode) a simple print statement. Eventually smaller pieces were added and contributions were made until the this privileged program was ready to do any heavy lifting.
Progress Marches On
Eventually, XOmB was able to execute a userspace and had system calls and working interrupt routines and preemption. A simple round-robin scheduler was implemented with high hopes for a more complicated scheme later. A userspace keyboard driver and a userspace textmode video driver was added and implemented using statically bound libraries. It was clear that the design goals we are concentrated on are possible. A console application had no reason to rely on system calls for IO, with the actual heavy lifting done via the libraries.
The Kernel Nears Completion
As another test, a usermode video driver (using VESA) was written so that an application could write to the frame buffer directly within userspace. Because of the nature of modern 64 bit x86 processors, VESA implementations had to be done using emulation of the 16 bit real mode video bios interfaces. These interfaces are about as old as the developers! In the end, legacy lost, as this driver was indeed successful. Toko bunga, Toko bunga online
With the experimental kernel complete, it was clear that we should use our experience to rewrite our codebase. Starting from scratch, we could focus on clarity and a modular design. It also gave us the time and opportunity to implement a bare bones kernel for others to use when writing their own operating systems. This project has received a very positive response and many have used this minimal template as part of their own "Genesis."
After a bit of work, the new XOmB has made it to userspace. With some effort, the newlib C standard library is being ported to work with XOmB. A simple C application has executed correctly on the kernel. In this rendition, XOmB uses a uniprocess scheduler, which simply allows for only one running process and no usage of auxiliary cores. However, system calls have not been implemented yet.
In early May 2011, XOmB had a working shell and limited file-system backed using page tables as metadata that ran on real hardware (an ASUS UL30VT laptop). We were pleasantly surprised to see that the keyboard worked even though we optimistically assume the keyboard scan set. The first task this XOmB instance performed was to have the shell, xsh, print out its own binary out to the console. Standard C applications also work.
- XOmB will run a compiler (LLVM+clang or GCC)
- XOmB will have a more full featured file-system (Although we love attribute-based, a.k.a. the less appropriately named link-based, file-systems)