[WARNINGS] link-id not found - [fmiosacomparativestudypartikernellandchapter1bootup|1 link-id not found - [fmiosacomparativestudypartikernellandchapter3scheduling|3 link-id not found - [fmiosacomparativestudypartikernellandchapter5memorymanagement|5 link-id not found - [fmiosacomparativestudypartikernellandchapter7deadlocks|7 link-id not found - [fmiosacomparativestudypartiiuserlandchapter8iolayers|8 link-id not found - [fmiosacomparativestudypartiiuserlandchapter10environmentlayer|10
Intro (I 1 2 3 4 5 6 7) (II 8 9 10 11) (D) (C) (B
I)
_Disclaimer:
_This is a work-in-progress. Everything you read on here is in draft form until January, 2007.
_You will find fluff, typos, unfinished chapters, mere outlines, dead pages, etc, until then.
_This is all pre-revision writing so you'll have to deal with it for now.
What does this mean for you? Well, you can *1)* Leave creative criticism and/or *2)* keep checking back for updates.
h1. Preface
This is a thesis that I, Dimitri Hammond, am writing as a comparative study between the open source project Flexible Microkernel Infrastructure Operating System (FMI/OS) and other popular operating systems. The goal of this thesis is to provide a topical view of the many different ways to piece together an operating system. The audience I am targeting is new (or seasoned) programmers who want to start down the difficult and scary path of coding an OS and those who want a good overview of how to do so.
My intention is that, upon completing this thesis, the reader will emerge with a good grasp of contemporary implementations of operating system concepts, especially those employed within the experimental OS, FMI/OS. Some details, such as specific algorithms and data structures, are left to future investigations of the reader. There are many other resources available that highlight the technical aspects of the topics to follow, and I will point the reader to some of them along the way.
h1. Introduction
(Why Another OS!?)
In this work each topic will start with some preliminary information and a quick refresher on a few terms. Machine Code (Assembly Language) is the language of the computer hardware; it is the natural language of computers. The Operating System (OS) is software that pulls together all of the hardware components, processors, disks, memory, etc., into a cohesive interface for all users and programs to use. The kernel is the name for the core of the operating system: the program that handles all the software-components controlling the hardware. Things that the kernel implements are considered to be in kernel space. Everything else, outside of the kernel, is considered user space, and is where software that uses the kernel's interface runs (managing files, graphical interfaces, games, word processing, etc).
Operating Systems come in all sizes. Windows, MacOS, UNIX, and SunOS are just a few of the popular platforms. One would argue that these few major forerunners are all that are really needed for the different niches to which they market. However, times are constantly changing and new and improved ways to do things are always in high demand. This is especially apparent when put into perspective of the fast-paced advances in the technology on which operating systems operate. Even today there is still a need for smaller, faster, more stable operating systems to control faster, more complex, and more compact devices.
One popular type of operating system design is the monolithic kernel design used in older UNIX and Windows. However, monolithic kernels tend to be very big, complex, and just plain messy in some areas. This is mainly due to their nature of having so much functionality implemented inside kernel space. The structure within the operating system that is needed to handle all of this functionality must be complex and can be quite susceptible to unexpected modular interactions. The code required to successfully implement everything in a monolithic kernel system tends to be large and complex.
Since the early 1980s, a new way to model the kernel has developed: the client-server microkernel model. The design of FMI/OS falls into this category. This is a much simpler model where kernel space and user space are divided differently from the monolithic design. In this newer model, most of the traditional OS functionality occurs in programs that reside outside the kernel in user space. Essentially, the kernel handles only processes and threads, their scheduling, message passing between them, as well as their memory management. Everything else, from device drivers to file systems to networking, takes place outside the kernel. This was a pretty radical idea, but is now incorporated in operating systems such as Chrous, MachOS, QNX, Minix, and Plan9. Yet, none of these microkernel designs separate the kernel and user spaces in the way that FMI/OS is designed, especially while maintaining POSIX compliance (POSIX is a standard for compatibility between UNIX-like operating systems).
Because of the close relation FMIOS has to operating systems QNX and Plan9, I will discuss them a lot in this thesis.
One of the uses of the microkernel design is as an embedded operating system. An embedded OS is hidden from users so they only speak to the OS via some nice interface. This is typically the case in cell phones or GameBoys or even fancy watches. These devices require a fairly small OS with limited functionality - only enough functionality needed for the limited application, necessitating the smallest, fastest, and cheapest way to build these devices. A microkernel is a good idea for this application because the kernel is small due to its simplicity, and the only things needed in user space are proprietary to the device.
Enter FMI/OS's future. This project is an endeavor tackled by a few people trying for a proof of concept. This project has grown from an academic project, called VSTa, to its practical counterpart now called FMI/OS. The history of its birth goes back a few years to a small number of developers who have since abandoned the project once they proved the concept and learned what they wanted from it. Only one of the original researchers stayed with the project, seeing its potential and continuing to want to learn more. He has since rekindled the project to the quickly growing, open source project it is today. Although only a few people are working on it, they are very active and pushing the OS on its way to actual completion.
Over the next few pages I will reveal the ways that we, the developers of FMI/OS, have tackled different problems, implemented different innovative ideas, and even made mistakes. With this I intend to engage the reader in our learning process. At the end of this work I will provide a summary snapshot of the state of our open source project.
h2. Part III Open Source Development
h2. Bibliography
h2. Index
(c)2006 Dimitri Hammond
h4. Comment by dam on Sun Dec 3 13:26:41 2006
Here's a To Do list for this thesis: wiki:FMIOSAComparativeStudy/TODO