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.
OS News needs real OS news, such as this one. Frankly, I’m sick of all those pieces about law suits.
krtekz,
I am tired of most of the mobile device coverage too, but you know what? I notice those articles get a lot more comments than these articles do. Granted, that’s probably because the fanboys/trolls jump all over them, but we have to face the sad possibility that maybe the real technical articles aren’t very appealing to most osnews readers.
If I could make a good living writing technical articles, I’d have a blast with it, but I don’t think the money’s there. If I’m wrong: Thom please contact me, I’m sure I can help cover some fascinating technical subjects
I also like this article and the way the author manages to get the technical details across without alienating me. Yes sometimes it is better to explain it to me like I am a 5 year old.
Boo to all the coverage the patent wars seem to get on OSnews. Bring back well written and easily understood technical articles.
Edited 2011-12-30 12:43 UTC
Yes, we need real OS news. Something about what people use or research, not someone’s CS 101 home assignment.
Believe it or not, we agree with you. We encourage readers to turn us on to interesting new projects, and we welcome submissions of articles.
Of course, a lot of readers also care about mobile and legal issues too, but we’d certainly like to publish more about alternative, experimental, and new OSes too.
First off, thanks for the technical article, these are why I come here.
“Dreckig (German for dirty, or messy) is a real-mode operating system designed for simplicity and performance.”
REAL-MODE?? Was that a misprint? Do modern compilers even generate that? I can’t think of one good reason to target real mode these days.
“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.”
Even if multitasking can be added, it would be very difficult to run more than one instance of any utility as designed.
I’m not clear what’s the technical difference between the “front end” and “back end”, but it’s odd that the shell is a backend component. Ideally it would just be another application.
I’m having trouble seeing what benefits this OS offers over others. Sure, loading a single file into RAM can be extremely fast, but that’s easily replicated by using an “initrd” image under linux.
I appreciate that almost all operating systems start out this way before they have real file systems, and that’s ok. But in the course of their existence they typically evolve to support dynamically loadable applications, it seems odd to stop with this design. Does Dreckig have any other strengths?
I’m looking at the source code right now, and it is definitely 16-bit, real mode. It’s… kind of refreshing, actually, in a way.
To the author, it might be nice to have some documentation as to your build process, for those of us who haven’t dealt with this sort of thing in a while.
Especially not if simplicity is a goal. Switching to protected mode is rather easy. I’d bet there are a lot of copy-this-code examples that you could just use (dunno, when I wrote my hobby OS I wanted to understand how it works, then wrote that one page of code myself), then have a flat, non-mapped 32-bit address space. That real mode segment juggling isn’t really “simple” when you actually try to code something.
This type of design is a nightmare for security. Putting common user land tools into the kernel makes it far too easy to miss something and open up a gaping hole.
Part of the reason we go through all the complexity with a micro kernel or even a well designed monolithic kernel is privilege separation.
Why even have a kernel? Why not just make a direct to hardware application? or make the whole application firmware. That’s what I’m sort of interested in. I believe that’s how a lot of electronics used to be made.
RichterKuato,
“Why even have a kernel? Why not just make a direct to hardware application? or make the whole application firmware. That’s what I’m sort of interested in. I believe that’s how a lot of electronics used to be made.”
osnews covered baremetal os a while ago…
http://www.osnews.com/story/24616/BareMetal_Node_HPC_kernel_in_6KiB
The idea is to write apps to run directly on hardware, but the OS aimed to eliminate the need to reinvent the wheel when it came to initialising the runtime. It also came with some networking support.
The problem with running custom apps in firmware is that firmware isn’t portable, the specs are closed, and it’s may not be possible to recover from a bricked system. Not that I haven’t wanted to do it.
Very interesting. I’m glad to see more actual OS news on OSNews.
However, this is pretty pointless if it is only in real mode. If the purpose of this architecture is to get speed and simplicity, this is ridiculously stupid. You have to jump through hoops to code for real mode, and it’s going to be slower anyway. Not to mention that you can’t do real IO (IIRC) and have to rely on super slow BIOS interrupts…
Zifre,
“However, this is pretty pointless if it is only in real mode. If the purpose of this architecture is to get speed and simplicity, this is ridiculously stupid. You have to jump through hoops to code for real mode, and it’s going to be slower anyway.”
Yep, I cannot think of a single good reason to design an OS around real mode today. 64K segments are a major impediment for any real load – unable to represent even a single bitmap without mucking around with intra-segment hacks. Even if those are overcome, you’re still limited to some 640K of base memory.
Of course you can use “flat real mode”, so the 64k limit is removed. But that implies switching to protected mode and back, why not just use protected mode?
“Not to mention that you can’t do real IO (IIRC) and have to rely on super slow BIOS interrupts…”
It’s not necessary to use BIOS interrupts in real mode any more than it is from protected mode. The only IO problem you’d have is reaching memory mapped devices that aren’t mapped within the first 1MB.
I remember when reading about SmallTalk-80 that the compiler and all the source code was included as one transparent package.
Can this system operate the same way? Thus when ever you need a new application added you just compile it into the kernel. Now additional major thing I remembered is that ST-80 worked with snapshots so if the newest version messed up the system you could just revert back to before you made any changes in the code.
Edited 2011-12-29 02:51 UTC
how does that differ from other OS’s that don’t segregate kernel and user?
Scary…dos is more powerful than this. Ripping out the security model you can still have installable applications, etc. You just have zero control on how well they play with each other.
I wonder how similar this is to the operating used on older game consoles. It seems like this is pretty much the same architecture as is on the WII (from my limited experience hacking it).
It also reminds me of the C-64, Atari 400/800, etc.
Interesting exercise – it’s good to re-check the ubiquitous assumptions once in a while.
Sorry, but it’s NOTHING like the A8 OS. The Atari had a rather sophisticated OS – everything was a device that you would open and send commands to. The screen was the ‘S’ device, the full-screen editor was the ‘E’ device, the cassette was the ‘C’ device, and so on. Programs were loaded from (floppy) disk or cassette like a normal OS, and called the OS through a central vector table. Clearly, there was no sense of user vs kernel because this was a 6502, but it was nothing like how this ‘Messy’ OS is described.
I was talking about the basic concepts, not implementation specifics.
The two main ways of running programs on those old systems are BASIC “programs” and ROM cartridges. The cartridge ROM is simply mapped into the “kernel” memory space, and BASIC programs are run by a built-in (i.e. “kernel”) interpreter. There was no differentiation between kernel and user space (memory, processor modes, etc.).
BTW, I found your information about the 8-bit Atari OS very interesting. I never had an Atari 400/800, and I love learning about these old systems. Sometimes they had very elegant solutions.
(The article didn’t seem to specify much about how device drivers and such would work in Dreckig OS, so I’m not sure if there are similarities or not.)
Like other users, I’m pleased to see more OS oriented news on OS news, although I understand the purpose of the other non-OS related articles (chiefly to draw traffic…).
Since ‘the cloud’ is all the rage these days, I think it would be cool if the OS pulled config/customizations/etc from there. I’m guessing networking isn’t implemented yet as it wasn’t discussed, but it would be interesting to have a unique OS lightly coupled with the cloud, even if only academically.
I think the project might be a little be flawed by design… well, judging it by this quote of yours at least.
Hi,
Often the primary goal of an OS like this is for the author to gain experience. From this perspective, you can say the design wasn’t flawed and the OS has met it’s primary goal.
– Brendan
The experience gained by working on this concept and seeing what it does well and what it does not is invaluable, you are correct and we agree on it.
I should have said “the architecture of the OS” instead of the project perhaps.
This is common in the embedded world.
In fact, I’m currently using Quadros, which is essentially the same concept.
http://www.quadros.com/
Exactly. In fact wouldn’t the megalithic architecture necessarily be embedded by design?
Why real mode? the same architecture could work in flat memory protected mode and have the benefit of the increased memory space.
I assume because that is the mode in which x86 cpus start off the BIOS?
I got the impression this OS being basically a multitasking DOS. Although I was kind of confused by the schematic diagram for its architecture, honestly.
Edited 2011-12-29 21:13 UTC
…what about paleolithic kernels?