ACM / Crossroads / Xrds9-2 / Comparing the Architectures of Component-based Operating Systems

Article Glyph

Comparing the Architectures of Component-based Operating Systems

Introduction

Researchers in the field of operating systems have made tremendous progress recently. Early operating systems came with monolithic kernels and layered architectures like UNIX and THE. Researchers soon realized the limitations of such inflexible designs. Today, most modern operating systems such as Windows NT/2000, Mach, Chorus, etc., are based on the micro-kernel architecture [25].

In the micro-kernel architecture, the kernel provides only the basic operating system abstractions like processes, memory management, and inter-process communication (IPC), and all other system services that used to reside in the kernel are implemented as external subsystems running in user space. In other words, operating systems based this architecture have much smaller kernels. Progress in operating systems has often been marked with shrinking kernel size. This kernel shrinking phenomenon inspired researchers to coin different terms to describe these kernel variants: pico-kernel, submicro-kernel [19], nano-kernel [13], nucleus, etc.

In a number of extensible operating systems like SPACE and Spring, the kernel, usually called the nucleus, is reduced merely to a thin veneer on top of hardware exporting very basic abstractions like portals and domains. Higher-level abstractions like processes, virtual memory, etc. are implemented in user space and can be configured, dynamically adapted, unloaded, and replaced. Multiple versions of standard abstractions can coexist.

The Exokernel architecture marks an extreme example of this trend. The Exokernel architecture advocates for a total extermination of all kernel abstractions. After all, no single set of abstractions can meet the needs of all applications in advance. The Exokernel nucleus is no more than a skimpy protection sheet over bare hardware. All standard operating system abstractions are implemented in user space by library operating systems. Applications may choose to talk directly to the nucleus or go through any library operating system of choice. This is clearly a great milestone in our kernel-shrinking progress. Is it possible to go any further?

The coming of software components marks a turning point in the design of operating systems. Components are strongly-typed objects that can be used as the building blocks for a system [15]. Components have clear interfaces that define the services they provide. Some researchers have begun to experiment with the notion of completely doing away with the kernel, in the traditional sense. They want to have something else at the heart of the operating system that is not a kernel. Some of them would want to have an Object Request Broker (ORB) managing component interaction, creation, and destruction, pretty much a la CORBA. Unlike in traditional operating systems, all tasks in these systems run in privileged mode. If all tasks run in privileged mode, we will have trouble stopping them from trying to overwrite each other's data. These researchers have devised different ways to ensure tasks are protected from each other. One of such schemes is code scanning, a novel technique employed in the Go! component-based operating system. Another recent component-based operating system that we are going to be looking into closely is the Pebble operating system. Pebble comes with a miniscule kernel that one can call a pico-kernel, to connote that it is an extremely small kernel.

Motivation

Modern operating systems are so large and complex that it is extremely difficult to customize their kernels for specialized use [8]. These operating systems define a fixed set of core abstractions like processes, IPC, virtual memory, etc. in a generic way. Genericity often leads to unfairness to certain classes of applications [4]. The justification for fixing these core abstractions has come under challenge recently [6], and a number of research projects [2, 1, 4, 7, 8, 10, 11, 22, 27] have sprung up attempting to explore alternatives to or variants of the micro-kernel architecture that currently represents the state-of-the-art in modern operating system design.

For any alternative approach to be viable, the following issues must be addressed:

The goal of universal applicability in operating systems will necessitate building dynamic extensibility and configurability into them
The need for performance drives the need for minimalism: why build what you don't need?
Reliability calls for an effective safety mechanism
Simplicity is desirable both in design and in usage

Clarke and Coulson [4] have classified the research efforts in this area into the following classes, based on the level of extensibility of the systems:

Build-time extensible systems are only configurable off-line. Reboot is required before the new configuration can take effect
Library extensible systems define a minimal nucleus (sometimes called pico-kernels) and applications can either be compiled and linked with library operating systems or make direct use of the minimal kernel facilities
Reflectively extensible systems rely on the concept of reflection to dynamically modify system implementation or environment for application benefit
Dynamically extensible systems extend kernel functionality by allowing applications to download extension code into the kernel address space

All of these categories can profit from component technology primarily because components are substitutable as long as the components maintain same interfaces. Components are typically used to compose systems in building block fashion [15]. One important feature of components is that they maintain strong interfaces. By strong interfaces, we mean specifications of what software components can do rather than how they do them. Thus, the extensible operating systems research community has turned its attention towards exploiting component technology in the design of operating systems. Components can form the building blocks of operating systems. Moreover, component frameworks such as CORBA [17], COM [3], and JavaBeans have proven to simplify development, promote reuse, reduce development time, ease maintenance, promote scalability, and lead to greater stability and robustness [26, 13].

This article describes recent efforts in this field and compares two new component based operating systems, namely, Go! [13] and Pebble [7]. The choice of these two is motivated by their popularity in current literature, and the fact that they are products of lessons learned from previously related projects. Thus they could be said to represent the progress made so far.

Related Work

In Small and Seltzer's paper [24], they have made a comparison of operating system extension technologies. In what follows, we discuss a few recent extensible operating system projects. We organize our discussion along the lines of Clarke and Coulson's classifications [4] presented earlier.

Build-Time Extensible Systems

Most operating systems we know such as Microsoft Windows ME/9x/2000, Unix, Linux, etc. fall in this category, since their kernels can all be extended by anyone by installing some patch or by modifying the source codes and then rebuilding. In either case, these systems would almost always require a reboot before these changes can take effect. However, there are times when rebooting is unacceptable. In such cases, one of the operating systems discussed in next three sections might be the way to go.

Library Extensible Systems

Spring [16] is a component-based, multithreaded micro-kernel distributed operating system that is binary compatible with Unix, using a Unix emulation subsystem. The main features of Spring include:

use of Interface Description Language (IDL) to define strong interfaces and thus language independence
micro-kernel architecture wherein most of the system is implemented as object managers (servers) running in non-kernel mode often in separate address spaces
server-based or serverless objects; nucleus supports the domains (processes), threads, and doors abstractions
provision of cross protection domain calls (object invocations) via doors; provisions of security through a combination of access control lists (ACLs) and software capability mechanisms
unix emulation provided through an emulation subsystem implemented as an object manager

The Exokernel [6] project aims at exterminating all operating system abstractions. The Exokernel architecture defines a minimal nucleus that merely provides protection over bare hardware. This demonstrates a very good performance. Common abstractions can be implemented in user space, and overall the Exokernel design illustrates the merits of minimalism and simplicity.

Reflectively extensible systems

Apertos [28] is a distributed object-oriented operating system that is based on a reflective architecture. The reflection follows from an object/meta-object separation. Each object is associated with a set of meta-objects that define the object's semantics. This set of meta-objects is called a meta-space. Each meta-object, being an object too, is also associated with a meta-space. This way, we have a meta-hierarchy. The essential thing is that objects can change the composition of their meta-spaces, and thus modifying their semantics. This ways new semantics and behavior can replace old ones in the components of the operating system.

Merlin (now renamed to Self/R) [5] is an object-oriented operating system developed using the Self programming language. Merlin is based on a reflective architecture that is very similar to that of the Apertos operating system. It has the same object/meta-space association. However, Merlin differs from Apertos in the implementation of its meta-spaces. We will not go into the details of this difference here, but interested readers might want to consult De Assumpção and Kufuji's paper [5] for the details. Merlin achieves extensibility in the same manner as Apertos.

The CHEOPS operating system [21] is an extensible operating system that uses reflection for adaptability and extensibility. A Class Object Manager (COM) manages the loading, removal, and exchange of components. Components can be dynamically added, removed, and exchanged thanks to a three level meta-modeling architecture where each class introduced to the system has a class object and a class-object-class. The system also maintains meta-level information such as available classes, the class hierarchy, etc.

Dynamically extensible systems

SPIN [2] supports extensibility by allowing modules to be dynamically added to the kernel. Protection is based on the use of a type-safe language (Modula-3), compile-time checks, and dynamic reference resolution. The core SPIN system services were designed with extensibility in mind; extensions (written in a type-safe language) extend the core functionality to specialize system services to individual applications. Extensions to SPIN are written in Modula-3. Modula-3 forces extensions to adhere to interfaces, thereby enforcing modularity. This safety system is implemented through compilation and run-time checking features. To achieve optimal performance, extension code is dynamically linked within the kernel address space, so as to avoid kernel crossings during kernel to extension communication. The safety of extensions in SPIN depends extensively on the use of the Modula-3 language. Although a number of arguments are given as to why this language is appropriate, efficient, and easy to use, the fact still remains that a great proportion of existing code is not in Modula-3. Specialization of operating system code to suit applications is clearly beneficial. Issues relevant to specialization are efficiency, safety, and flexibility. SPIN demonstrates that efficiency can be achieved through co-location, and flexibility through careful design. Safety can also be achieved, but at the cost of imposing limitations on the language used and/or the extension code's functionality.

VINO [23] is a downloadable system that uses sand-boxing to enforce trust and security. Extensions are written in C++ and are compiled by a trusted compiler that prevents the extension from accessing text or data outside its own address range, except for permitted entry points. This trusted code is then downloaded into the kernel. The major strengths of this method are that performance is only slightly worse than unprotected C++ and extensions can be implemented in conventional languages. To facilitate graceful recovery from an extension failure, VINO runs each extension in the context of a transaction. If the extension fails or must be aborted (because it is monopolizing resources), the transaction mechanism undoes all actions taken by the extension. VINO extensions are bound with resources, including both applications and files, so extensions persist across system reboots and kernel upgrades. The VINO kernel is constructed from a collection of objects. Extensibility is provided by replacing or overloading specific methods on those objects, resulting in a limited procedural extensibility model. Moreover, VINO objects are designed so that all policy decisions are implemented in simple member functions that can be replaced or overloaded.

MMLite [11] does not define a kernel entity, nor any fixed core abstractions. Abstractions that are typically designed into an operating system, such as virtual memory management and inter-process communication, are loadable components in this system. MMLite employs a unified programming model that is independent of the privilege issue (i.e., no user vs. kernel distinction). Mutation makes possible extensibility down to the granularity of a method call. Mutation allows methods to be dynamically replaced at clean points. The Microsoft COM Model is employed and IPC can be LPC or RPC depending on the location of the caller and the callee (transparent remote invocation). The focus of the MMLite design is on adaptability, minimalism, and reusability.

DEIMOS [4] defines no kernel entity. However, the Configuration Manager (CM) serves the purpose of a micro-kernel guarding access to shared hardware resources, more or less like the Exokernel architecture. An abstraction called modules, similar to components, is the unit of extensibility in DEIMOS. Distinction is made between core modules, which have privilege status, and application modules. All modules are loadable and unloadable including the CM module. A hardware protection mechanism is used to protect the DEIMOS core modules, but currently application modules are not protected from each other.

The next two sections describe two recent component-based operating systems that have recently gained attention of researchers, e.g. Pebble and Go!.

Pebble

Pebble [7] is a new operating system developed for MIPS-based processors at the Information Sciences Research Center at Bell-Labs. Pebble is designed for flexibility, safety, and high performance. Pebble supports composing an operating system out of fine-grained components, each running within its own protection domain (PD). A PD is simply an execution environment, made up of a set of pages (represented by a page table) and a set of portals stored in the PD's portal table. The portal is a conceptual generalization of an interrupt handler, inherited from the SPACE operating system [19]. In Pebble, PDs may share a portal table as well as pages. The key philosophy behind the design of Pebble is in making the nucleus as lean as possible. If anything can be run at the user level, it is removed from the nucleus and taken to the user level. The nucleus simply switches between protection domains. User-level operating system components are the units of extensibility.

Figure 1: Portal traversal in Pebble goes through the nucleus [7].

Pebble implements a safe execution environment by a combination of hardware memory protection and the portal mechanism. Hardware memory protection restricts memory access within the PD (i.e., pages in its page table), while the portal mechanism limits a PD to portals within its portal table.

Each component running within a PD is made up of one or more threads. Threads may only transfer control to other PDs by invoking its PD's portal table.

System services like scheduling, memory management, and virtual memory are provided by operating system server components (which run in “user mode” PDs). Unlike application components, server components are trusted, so they may be granted limited privileges not afforded to application components.

Pebble can intercept calls made by clients to its servers and then interpose modifiable code operations of the server, enforce safety policies and a host of other functions. This is possible because each portal invocation involves generation of portal-specific code. This mechanism allows for the optimization of PD traversal codes on a per portal basis. And this is the basis of Pebble's flexibility and dynamic extensibility: custom portal traversal codes (Figure 1).

Go!

Go! [13] is a new component-based operating system developed at the Department of Computing at City University, London. Go! does away with a dual processor mode address space: All components, either system components or application components, (together with an ORB) run in privileged mode. Most components are prevented from containing instructions that would be illegal in user mode, through a mechanism called code scanning. When loading a component, its code section is examined for instructions it is not sufficiently privileged to execute. Only when a component is free of such code is it allowed to run.

The ORB only handles component lifetime management and inter-component method invocation and return (Figure 2). It is application-level components that manage devices, paging and handle interrupts, etc.

Figure 2: Inter-Component Communication is brokered by the ORB in Go! [8].

The only implementation of Go! available at the time of writing uses a segmented paged memory scheme on the Intel IA32-based machines [12]. The orthogonal combination of segmentation with paging has well known advantages [25]. For example, an address generated by an instruction (known as a logical address) is converted into a linear address using the segmentation model. The linear address is then fed through the paging hardware to generate a physical address [14].

Pebble vs. Go!

In this section, Pebble and Go! are compared based on the following features:

protection levels
protection mechanism
interrupt handling
extensibility
multithreading
performance
open-source design

Protection Levels

In Pebble, only the nucleus runs in privilege level 0, while all other components run in user space. In Go!, however, everything runs in privilege level 0.

Protection Mechanism

Protection in Pebble is maintained by the hardware paging protection mechanism. A thread executing within a PD may not access pages outside the PD's page table. If it must, then it has to go through the portal mechanism. The portal mechanism will migrate the thread into the PD that contains the target page. That way it can access the page table of that PD. This is only possible if the invoking PD has the portal of the invoked PD listed in its portal table. Normally, when such a portal traversal happens, the thread loses its access to its source PD until it returns. There are cases when the portal code would manipulate the portal table of the invoked PD and/or invoking PD to give the thread a window into the address space of its source PD. This window is shut as soon as the thread returns home.

Since all components in Go! run at privilege level 0, they inherently have access to all memory addresses. This is possible because hardware memory protection schemes allow a piece of code to access segments/pages for which its clearance level (privilege level) is lower than or equal to. Thus, hardware memory protection is not possible since every piece of code has the most privileged clearance level (level 0). Go! ensures codes don't access memory locations they are not authorized to by employing code scanning.

Interrupt Handling

Pebble hides the details of interrupts from higher-level components and uses only semaphores for synchronization. Any interrupt is caught in the nucleus by a short trampoline function [7] that merely invokes the appropriate portal. It obtains this portal from the portal table of the active thread's PD. Essentially, the nucleus delegates the interrupt handling to a portal. The invoked portal will then invoke the interrupt dispatcher server. The interrupt dispatcher determines the source of the interrupt and performs a V operation on the source's semaphore. Typically, a thread would already be waiting on that semaphore. This is an application of the chain-of-control design pattern.

In Go!, on the other hand, the ORB has no business handling interrupts. Application level components can handle interrupt since they also run in the most privileged mode. Typically, an interrupt handler component will be installed. Here, no mode switching is required which speeds up interrupt handling tremendously.

Extensibility

The units of extensibility in Pebble are the user-level components. Extensibility can be achieved either by adding or replacing a user-level component or via portal interposition. A whole library operating system may be layered on top of Pebble using this mechanism.

In Go! extensibility is also achieved by installing a new component or by replacing an existing one. Go!, like Pebble, can also be extended by installing a library operating system component on top of which existing binaries that are executable (eg. Exokernel [6]). Multiple library operating systems may coexist.

Multithreading

Pebble is inherently multithreaded, with the thread abstraction being part of the system. However, this is not the case for Go!. The Go! ORB has no notion of threads. However, a server component may implement a threading model, and application components needing thread functionality may invoke the services of such a component. Multiple such thread manager components may coexist, each implementing the same or different threading model.

Performance

Owing to a number of constraints, the author was unable to compare the performance levels of both operating systems. Currently, the only implementation of Pebble we know of runs on a MIPS-base machines, while Go! runs on Intel IA32-based systems. Ports are, however, planned for both systems [7, 14]. However, benchmark results, available at the Go! Homepage [9] suggest that Go! is better in performance.

Open-source Design

According to information on the Pebble homepage [18], its source code will soon be made available for non-commercial uses only. On the other hand, Go! is free and open-source software. It carries the GPL license. Go! is accessible from its project homepage [9]. What's more, the Go! project is open to any developer who might want to contribute.

Concluding Remarks

Whereas the two operating systems adopt the same software engineering paradigm (component technology), they belong to different operating system design paradigms and represent markedly different kernel sizes.

While employing different mechanisms, both Pebble and Go! are dynamically adaptable systems and have both attempted to implement minimal systems.

Pebble, on the one hand, takes a well-known and well-tested paradigm a step further, with fewer risks. Go! is more adventurous and drastic in its approach. Although the Go! design is appealing in its simplicity, its protection model is difficult to prove correct.

I expect future component-based systems will take dynamic extensibility, minimalism, safety, and simplicity to even greater extremes.

Glossary

ACL - Acronym for Access Control List. A database that lists the valid users of the system and the level of access they have been granted.

Adaptability - Ability to adapt to change say through graceful degradation, rather than abruptly crashing.

Address space - The range of memory locations that available to a computer program.

Admission testing - A mechanism employed in RTOS's where the scheduler checks whether there is still sufficient resource available to run a task. It starts executing the task only if there are enough to run it to completion without missing its deadline.

Application-level - A privilege level for applications that run in user space, which usually restrict them from dealing directly with the hardware or encroaching into another application's address space.

COM - Acronym for Component Object Model. A standard developed by Microsoft Corporation that enables conforming objects to communicate with each other even if the objects have been created using different programming languages.

Configurability - The ability to configure an operating system (at compile, link, or distribution time) to take on different personalities

CORBA - Acronym for Common Object Request Brokerage Architecture. A middleware standard that enables objects to communicate with each other in a way that is platform- and programming language-independent.

Distributed operating system - A common operating system shared by a network of computers. It will typically provides support for IPC, process migration, mutual exclusion, and the prevention or detection of deadlock.

Dynamism - The capability to change the implementation of components without shutting them down. Also known as 'hot-swapping'.

Extensibility - Ability to extend the kernel with custom services (or new abstractions) not built into it out-of-the-box.

Extension code - Code that is loaded into the kernel in an extensible operating system.

Flexibility - This refers to the ability of a single operating system to present different views of itself to concurrently executing applications, and change the operating system's behavior dynamically.

Garbage-collection - A process by which a program goes through memory, decides which information stored there is no longer needed, and frees the memory address they occupy for reuse.

GPL - Acronym for General Public License. An open-source software license developed by the Free Software Foundation (FSF) that grants licensees the right to copy, examine, and modify the source code as long as subsequent distributions extend the same privileges to new recipients.

Hardware Protection - Hardware mechanisms which ensure that task cannot access each other's address spaces.

IA32 - The instruction set for Intel Corporation's 32-bit microprocessors.

Interface - A specification of the set of services that a component can provide.

Interrupt - A signal to the microprocessor indicating that an event has occurred that it needs to attend to. When an interrupt is being occurs, processing is suspended in a way that it can be resumed.

Interrupt handler - A routine, usually part of the operating system, that executes when an interrupt occurs.

Java bytecode - A compiled Java code with extension .class that can be executed by the Java interpreter, the JVM.

JavaBeans - A component architecture for Java programs that enables Java programmers to package Java programs in a container for increased interoperability with other objects and improved security.

JVM - Acronym for Java Virtual Machine. A Java interpreter and runtime environment for Java applications.

Kernel - The crux of an operating system. It is the most heavily used part of the operating system. The kernel is often permanently maintained in main memory. The kernel is often the only part of a system that runs with full access privileges to the underlying hardware. Core operating system abstractions such as memory management, IPC, interrupt handling, scheduling, etc. are often implemented in the kernel, especially in monolithic kernels.

MIPS-based processors - Processors based on 32- and 64-bit RISC (reduced instruction-set computing) microprocessor designs from MIPS Technologies, Inc., which does not manufacture processors. Instead, thet license several vendors to produce MIPS-based processors.

Mode switching - A hardware operation that occurs that causes the processor to execute in a different mode (kernel mode or user mode). When the mode switches from process to kernel, the contents of the program counter, processor status word, and other registers are saved. When the mode switches from kernel to process, this information is restored.

Monolithic kernel - A large kernel containing virtually the whole operating system.

Multithreading - Ability to have several sequences of control within a single process. A multithreaded process is capable of several independent actions at the same time. When multiple processors are available, those concurrent but independent actions can take place in parallel.

Nucleus - A small kernel.

Open-source Design - Making source code available for use or modification as users or other developers see fit, provided the modified source is also made available. Open source software is usually developed as a public collaboration and made freely available.

ORB - Acronym for Object Request Broker. A “object bus” connecting different components by forwarding operation invocations from client to server components. While doing this, it transparently handles name resolution, type checking, component instantiation and destruction, etc.

Paging - Transfer of pages between main memory and secondary memory.

Privilege levels (PL) - A set of levels that characterizes instructions and processes in such a way that processes can execute only those instructions they are authorized to. Privilege Level 0 means that the program can execute all CPU instructions. This the PL the kernel has. Other programs have higher PLs. The lower the PL is, the more the program is allowed to do. Programs are only allowed to call functions which have the same or lower PL.

Privileged mode - The processor execution mode in which the kernel runs and privileged instructions (such as altering a control register) can be executed. Also called the kernel mode.

Process - A program in execution.

Processor mode - Any of a set of execution modes in which the processor runs. Each mode has a set of instructions that it is allowed to execute.

Protection domain - A program's execution environment that is usually protected by hardware protection mechanisms.

Reflection - Ability to discover information at runtime.

RTOS - Acronym for real-time operating system. An operating system that guarantees a certain capability within a specified time constraint.

Sand-boxing - A scheme for ensuring safety in an (say in an extensible operating system) by limiting the range of address the code can reference, so that it does not get to cause unexpected harm.

Scheduler - An operating system component that selects tasks or jobs that are to be executed.

Segmentation - The division of a program or application into segments as part of a virtual memory scheme.

Semaphores - An integer value used for signaling among processes. Only three operations may be performed on a semaphore, all of which are atomic: initialize, decrement, and increment.

Synchronization - Situation in which two or more processes coordinate their activities based on a condition.

Thread - A sequence of control within a process.

User mode - The processor execution mode in which privileged instructions (such as altering a control register) cannot be executed.

User space - The range of memory addresses that non-kernel programs are allowed to use in conventional operating systems.

Virtual memory - Hard disk space that is used as an extension for the RAM.

References

1: Back, G., P. Tullmann, L. Stoller, W. C. Hsieh, and J. Lepreau, "Java Operating Systems: Design and Implementation," Technical Report UUCS-98-015, University of Utah, August 1998.
2: Bershad, B. N., S. Savage, P. Pardyak, E. G. Sirer, M. E. Fiuczynski, D. Becker, C. Chambers, and S. Eggers. Extensibility, safety and performance in the SPIN operating system. In Proceedings of the Fifteenth ACM Symposium on Operating System Principles, pages 267-284, Copper Mountain, CO, Dec. 1995.
3: Box, D. Essential COM. Addison-Wesley, 1998.
4: Clarke, M., Coulson, G. "An Architecture for Dynamically Extensible Operating Systems." In Proceedings of the 4th International Conference on Configurable Distributed Systems (ICCDS'98), Annapolis MD, USA, May 1998.
5: De Assumpção Jr., J.M. and S.T. Kufuji. Bootstrapping the Object-Oriented Operating System Merlin: Just Add reflection. Technical report, Laboratorio de Sistemas Integraveis, University of São Paulo, Brazil, 1994
6: Engler, D. R., M. F. Kaashoek, and J. OÕToole. Exokernel: An Operating System Architecture for Application-Level Resource Management. In Proceedings of the Fifteenth ACM Symposium on Operating System Principles, pages 251-266, Copper Mountain, CO, Dec. 1995.
7: Gabber, Eran, Christopher Small, John Bruno, Jose Brustoloni, and Avi Silberschatz. The Pebble component-based operating system. In Proceedings of the 1999 USENIX Technical Conference, pages 267-282, Monterey, CA, USA, June 1999.
8: Ghormley, D. et al. SLIC: An Extensibility System for Commodity Operating Systems. In Proceedings of the Unsenix Annual Technology Confference, Usenix, Berkeley, CA, 1998, pp. 39-48.
9: Go! Home Page. http://goos.sourceforge.net/home.php (23 July, 2002).
10: Heiser, G., K Elphinstone, J. Vochteloo, S. Russell, "The Mungi Single-Address-Space Operating System," Software: Practice & Experience, 18(9), 25 July 1998.
11: Helander, J and A. Foring. MMLite: A Highly Componentized System Architecture. In Proceedings of the Eighth ACM SIGOPS European Workshop, pp. 6-17, ACM Press, New York, 1998.
12: Law, G. and J. McCann, 26 bit Selections on IA32. In EWOOOS at ECOOP 2000.
13: Law, G. and J. McCann, A New Protection Model for Component-Based Operating Systems. In Proceedings of the IEEE Conference on Computing and Communications, Phoenix, AZ, USA, February 2000.
14: Law, G. and J. McCann, Decomposition of Preemptive Scheduling in the Go! Component-Based Operating System. In ACM SIGOPS European Workshop, 2000.
15: Messer, A. and T. Wilkinson, Components for Operating System Design, In Proceedings of the International Workshop on Object Orientation in Operating Systems (IWOOOSÕ96), Seattle, WA, USA, October 1996. IEEE.
16: Mitchell, J. G., J. J. Gibbons, G. Hamilton, P. B. Kessler, Y. A. Khalidi, P. Kougiouris, P. W. Madany, M.N. Nelson, M. L. Powell, and S. R. Radia, "An Overview of the Spring System", In Proceedings of COMPCON, February 1994.
17: OMG. CORBA/IIOP 2.2 Specification. http://www.omg.org/corba/corbiiop.htm
18: Pebble Home Page. http://www.bell-labs.com/project/pebble/ (23 July, 2002).
19: Probert, D., J. L. Bruno, M. Karaorman, "SPACE: A New Approach to Operating System Abstraction," In Proceedings of the International Workshop on Object-Orientation in Operating Systems (IWOOS), pp. 133- 137 (1991). ftp://ftp.cs.ucsb.edu/pub/papers/space/iwoos91.ps.gz.
20: Rozier, M., A. Abrassimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Hermann, C. Kaiser, S. Langlois, P. Leonard, W. Neuhauser. CHORUS distributed operating system. In Computing Systems, pp. 305-370, Vol. 1-4, 1988.
21: Schubert, F.: A Reflective Architecture for an Adaptable Object-Oriented Operating System Based on C++. ECOOP Workshops 1997, pp. 515-522.
22: Seltzer, M., Endo, Y., Small, C., Smith, K., "An Introduction to the Architecture of the VINO Kernel". Harvard University Computer Science Technical Report 34-94, 1994.
23: Seltzer, M., Y. Endo, C. Small, and K. Smith, Dealing with Disaster: Surviving Misbehaved Kernel Extensions. In Proceedings of the 2nd OSDI Conference, pp. 213-227 (1996).
24: Small, C. and M. Seltzer, "A Comparison of OS Extension Technologies," In Proceedings of the 1996 USENIX Technical Conference, San Diego, CA, Jan. 1996, pp. 41Ñ54.
25: Stallings, W. Operating Systems: Internals and Design Principles. 4th Ed. Prentice-Hall. 2001.
26: Stankovic, J. A. VEST: A Toolset of Constructing and Analyzing Component Based Operating Systems for Embedded and Real-Time Systems. University of Virginia Technical Report, July 2000.
27: Wilkinson, T. and K. Murray. "Extensible, Flexible and Secure services in Angel, a single address space-operating system." In International Conference on Algorithms and Architectures for Parallel Processing (ICA3PP), pages 755-758, Brisbane, Australia, April 1995. IEEE.
28: Yokote, Y. The Apertos Reflective Operating System: The Concept and its Implementation. OOPSLA 1992, pp. 414-434

Biography

Raimi Rufai (rrufai@acm.org) is a Research Assistant at King Fahd University of Petroleum & Minerals (KFUPM) in Dhahran, Saudi Arabia. He holds a Bachelors Degree in Computer Science from University of Ilorin, Nigeria. He is currently pursuing his MS degree in Computer Science at KFUPM. His interests are in Software Reuse, Software Metrics, Design Patterns, and Operating Systems.

The author wishes to thank King Fahd University of Petroleum & Minerals for their support in the studies that produced this work. He would also want to thank all those who have helped review this article.

Crossroads

The ACM Student Magazine