There are two main kernel architectures for large operating systems; monolithic and micro. While these architectures are well thought out, well implemented (usually), and well understood, they have their faults. Mainly, the loading of modules and executables, management of memory, and interfacing between the kernel and software cause these architectures to be vastly complex. With this complexity comes a loss of speed and increased difficulty for the developer. There are other kernel architectures, such as the exokernel, that are vastly different from traditional architectures, but they still have performance issues caused by userland processes.
There is, of course, a solution to these issues. By coding all the usual userland software, drivers, and, well, everything else, into the kernel the speed and simplicity of the operating system can be increased. This architecture takes the UNIX philosophy of everything being a file and goes one step further, everything is one file. This architecture is the under-used, often under-appreciated, megalithic kernel. The principle behind the megalithic kernel is that by simplifying how the kernel and its software works, performance can be improved. This is the idea behind my project Dreckig OS.
Dreckig (German for dirty, or messy) is a real-mode operating system designed for simplicity and performance. By incorporating everything into the kernel, the need for memory management, file system access, loading of software, and many other processes used by other operating systems are eliminated. The only time anything needs to be loaded to memory is at boot, which is handled by the boot-sector.
To help make sense of how this works, here is a diagram of the kernel:
In Dreckig the user interfaces with the kernel, and the kernel interfaces with the computer. More accurately, the kernel can be broken down into two main parts, the front end, and the back end. The front end is the part that the user actually sees and uses, sort of like the userland in most operating systems. The back end is where the business actually gets done, what would be traditionally looked at as the kernel-mode. Let's start out by describing the front end.
In the front sits the UI (user interface); Dreckig currently uses a command line interface, but a GUI is in the works. The UI is what gives and takes information to and from the user. The UI is connected to back end parts, but that will come later. The UI is also connected to all the applications in Dreckig. Applications give and take data through the UI, applications also are connected to the back end.
In the back end of the Dreckig kernel are the Shell and Kernel Utilities. The shell is really just a loop that calls to the UI to get input from the user, and calls to the kernel to launch applications based on the input. What makes up the rest of the back end is the Kernel Utilities. This is what really makes the kernel tick. The utilities are connected to the shell and all other applications in the kernel. When an application needs to do something, like print to the screen, or convert strings, it calls to the kernel utilities, which does the task for the application.
The megalithic kernel architecture used in Dreckig has its advantages, mainly speed and simplicity, but it also has some major flaws. The megalithic architecture is not very flexible. Since it cannot execute anything outside the kernel it cannot install new software; while this eliminates the possibility of viruses, it also makes it so the user could not develop software or even use third party software in Dreckig, unless they rewrote parts of the kernel. Multitasking becomes very impractical when only one process can execute. Workarounds can be written to do multi-threading and run different parts of the kernel at the same time, but this can lead to memory protection errors.
Another issue caused by the Megalithic architecture lies in file systems. Since the entire OS is in one file a file system is almost useless, only being needed on boot. Since the kernel doesn't load anything to RAM any settings would need to be written into the kernel, and then written to disk. This could lead to some issues when more complex and customizable software is written, as preferences could not be easily saved from boot to boot. One solution could be to have a section of the kernel padded out with zeros, and then write data to that, and on exit from the OS write that chunk back to disk. With this idea fragmentation could pose an issue. Due to this strangeness with file systems text editors and other software that make files would be impractical to implement.
Although the megalithic kernel architecture, used in Dreckig OS, seems simple in theory, in practice it can be anything but. Its simplicity causes the need for complex ways to make it usable and useful. This architecture does address and fix some of the problems with traditional kernel architectures, but in doing so it introduces its own bizarre issues. Thanks to its relative protection from viruses, speed, simplicity and lack of need for file systems a megalithic kernel would be well suited for embedded devices.
Dreckig OS is released under the GNU GPL v3 and can be downloaded here. Currently, Dreckig is still in alpha; in the coming releases I will be adding functionality and stability.
Text: Sean Haas
