[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)

h1. Part IV: Conclusion

h2. 1. Summary

The open source project FMI/OS is a POSIX-compliant, microkernel-based, client-server OS modeled after QNX and Plan9. Below are some of the highlights of the implementations of key components.

h4. Bootup Procedures

Booting a microkernel takes extra help from the bootloader, as opposed to monolithic kernels, which handle most things on their own (within the kernel). FMI/OS requires the bootloader to pre-load a few modules into memory and pass the addresses of those along to the kernel in the form of a multiboot header.

During boot time, the kernel takes these modules, which are actually user space servers, and runs them to aid in the initialization of certain key services such as an IPC translator, disk driver, and filesystem server.

h4. Scheduling

The FMI/OS scheduling API deals strictly with threads. It establishes a Preemptive Cooperative Multitasking Environment where scheduling events are only called in message passing routines, interrupt handlers, or other semaphores. They utilize POSIX Realtime-compliant round robin and FIFO techniques on a specialized priority class data structure. Accessing the processes in this list occurs with a constant-time algorithm, regardless of the number of processes the list contains.

Badness and goodness factors are incorporated to allow an accordion effect of threads to prevent stagnation. Also incorporated is priority inheritance within child process (and thread) creation and message passing.

h4. Internal Communication

An IPC system is used for passing messages between clients and servers, and between servers, themselves. Servers are assigned port addresses which are handled with the translator @namer@. Message passing functions are atomic, within the kernel, to maintain the integrity of their critical regions.

Shared interrupts are used, with each having two subscriber lists: @ready@ and @pending@. An interrupt handler would use ISR commands to send messages through the IPC to the subscribed servers residing in the handler's @ready@ list. Servers that have already received a message from the handler, but have not yet responded, are in the handler's @pending@ list.

h4. Memory Management

Memory is managed by a system similar to NetBSD's UVM. This employs a functional and portable API that's layered based upon machine-dependent and machine-independent routines. Each process has their own VAS, and copy-on-write is also often utilized.

Porting the UVM from a monolithic kernel to a microkernel has resulted in a culling of different functionality. As a result, the pager has been temporarily removed with plans to brainstorm more effective ways to implement it.

h4. Symmetric Multiprocessing

An SMP model has been used along with a timesharing scheduling algorithm. Due to the constant-time traversal of the run tree, heavy bottlenecking is avoided. Through the use of auto locks, which turn off a CPU's interrupts during a lock, re-entrance of interrupt handlers can be avoided. Other deadlocking is avoided by careful lock ordering.

h4. I/O and Orthogonality

One of the most important concepts that FMI/OS borrows from Plan9 is orthogonality. This means that everything, from physical files to devices to servers, are represented as files. With this, traditional manipulation of files and directories within the filesystem can serve as an interface to a device or server. Also, there is the added functionality of binding and mounting files and directories.

When communicating with an I/O device, FMI/OS guises synchronous communication as asynchronous using its ABC, or asynchronous buffer caching.

Orthogonality, used in conjunction with the IPC, also allows for the future possibility of easily achieving network transparency.

h4. User Space Details

Currently, we plan on porting glibc to FMI/OS, replacing its @libio@ with a proprietary FMI/OS library to supply glibc with the “syscalls” it needs. This layered approach would allow for the possibility of future ports of different (non-POSIX) environments, such as Windows or MacOS.

Testing will occur with a test shell called @testsh@ that will test some of the fundamental functionality of the kernel (such as the IPC and memory manager). Otherwise, the @bash@ shell handles normal command line commands.

h2. 2. Future Outlook

As I finish writing this thesis, one-fifth of it will already be out of date. As it becomes published, one-third will be out of date. The sheer nature of an open-source project is that it is always changing. These changes come as better and more efficient ways for doing things come about.

FMI/OS is still in its academic stages as we all continue to learn and piece everything together. Despite this, our development, testing framework, and kernel are already getting recognition. Companies are approaching our development staff with different contracts, as a result. This is the beauty of Open-Source Development. You may not make money by selling licenses for people to use your software, but your achievements do not go unrecognized, and are often followed by a hefty requite.

However, rarely is it about the money. FMI/OS was started as an academic project for those involved to learn how to write a successful microkernel. And for that, it has succeeded immensely. In the course of writing this thesis, I, too, have learned much about, not just FMI/OS, but all operating systems and their methods. Hopefully those reading have shared in this insight, as well.

This thesis is a stepping-stone to much more work to do on FMI/OS, and much more to learn about computers and operating systems. I bid those who go on to further research the topics discussed: good luck and have many great adventures as you go on to learn and accomplish great things!


(c)2006 Dimitri Hammond

AddComment

Also available in: HTML TXT