Dreckig OS与巨型内核

导读：
大型操作系统有两大内核架构——巨型和微型（monolithic and micro）。虽然它们都是经深思熟虑过的，有良好的实现，并容易被理解，但还是有各自的不足。对模块和可执行程序的载入，对内存的管理，以及与内核和软 件的交互，使得这些架构变得非常复杂。随复杂而来的，则是速度的降低，以及对开发人员复杂度的提升。还有其他内核架构，如exokernel，它们极不同 于传统架构，但也仍然存在由用户域（userland）进程引起的性能问题。
本文则是作者提出并亲身实践的一个解决方案。他通过将所有用户域软件、驱动以及其他一切写进内核，使操作系统内核的速度和简单性得到提升。这一架构采用 UNIX“万物皆文件”（everything is a file ）的哲学思想，并更进一步地，一切皆一个文件（everything is one file）！该构架属于已经被使用的、被欣赏的巨型内核。巨型内核背后的法则是，通过简化内核及其软件的工作，性能得以提升。这也是作者 Dreckig OS项目背后的思想。
Dreckig OS内核构架图如下：

Dreckig OS在GNU GPL v3 许可下发布，下载地址： http://code.google.com/p/dreckig-os/。当前尚处理Alpha版本，在接下来的版本中将加入新功能并提升其稳定性。

转载请注明：Linux人社区> 英文资讯翻译专版.编译

英文原文：
Dreckig OS and the Megalithic Kernel
posted by Sean Haas on Wed 28th Dec 2011 23:41 UTC
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.