Comparing the Architectures of

Component-based Operating
Systems
by Raimi Rufai

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 ([email protected]) 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.