Comparing the Architectures of Component

8/8/2019 Comparing the Architectures of Component

1/26

Comparing the Architectures of

Component-based Operating

Systems

by Raimi Rufai

Introduction

Researchers in the field of operating systemshavemade tremendous

progressrecently. Early operating systemscame withmonolithic

kernelsandlayeredarchitectureslike UNIX and THE. Researcherssoon realized thelimitations ofsuch inflexibledesigns. Today, most

modern operating systemssuchas Windows NT/2000, Mach, Chorus,

etc., are based on themicro-kernelarchitecture [25].

In themicro-kernelarchitecture, the kernel provides only the basic

operating systemabstractionslike processes, memory management,

and inter-processcommunication (IPC), andall othersystemservices

that used to reside in the kernelare implementedasexternal

subsystemsrunning in userspace. In other words, operating systems

based thisarchitecturehavemuchsmaller kernels. Progress in

operating systemshas often been marked withshrinking kernelsize.

This kernelshrinking phenomenon inspiredresearchers to coin

different terms to describe thesekernel variants: pico-kernel,

submicro-kernel [19], nano-kernel [13], nucleus, etc.

In a number ofextensible operating systemslike SPACE and Spring,

the kernel, usually called thenucleus, isreducedmerely to a thin

veneer on top ofhardwareexporting very basicabstractionslike

portalsanddomains. Higher-levelabstractionslike processes, virtual

memory, etc. are implemented in userspaceandcan beconfigured,


2/26


3/26

Pebblecomes withaminiscule kernel that onecan callapico-kernel,

to connote that it isan extremely small kernel.

Motivation

Modern operating systemsareso largeandcomplex that it is

extremely difficult to customize their kernels forspecialized use [8].

These operating systemsdefinea fixedset ofcoreabstractionslike

processes, IPC, virtualmemory, etc. in a generic way. Genericity

often leads to unfairness to certain classes ofapplications [4]. The

justification for fixing thesecoreabstractionshascome under

challengerecently [6], anda number ofresearch projects [2, 1, 4, 7,

8

, 10, 11,22

,27

]havesprung up attempting to explorealternativesto orvariants of themicro-kernelarchitecture that currently

represents thestate-of-the-art in modern operating systemdesign.

Forany alternativeapproach to beviable, the following issuesmust

beaddressed:

y The goal ofuniversal applicability in operating systems willnecessitate building dynamicextensibilityandconfigurability

into them

y The need forperformancedrives the need forminimalism: whybuild what you don't need?

y Reliabilitycalls foran effectivesafety mechanismy Simplicityisdesirable both in design and in usage

Clarkeand Coulson [4]haveclassified theresearchefforts in this

area into the following classes, based on thelevel ofextensibility ofthesystems:

y Build-time extensible systemsare only configurable off-line.Reboot isrequired before the new configuration can takeeffect


4/26

y Library extensible systemsdefineaminimal nucleus(sometimescalledpico-kernels) andapplicationscan either be

compiledandlinked withlibrary operating systems ormake

direct use of theminimal kernel facilities

y Reflectively extensible systems rely on theconcept ofreflectionto dynamically modify system implementation orenvironment

forapplication benefit

y Dynamically extensible systemsextend kernel functionality byallowing applications to downloadextension code into the

kerneladdressspace

All of thesecategoriescan profit fromcomponent technology

primarily becausecomponentsaresubstitutableaslong as the

componentsmaintain same interfaces. Componentsare typically used

to composesystems in building block fashion [15]. One important

feature ofcomponents is that they maintain strong interfaces. By

strong interfaces, wemean specifications ofwhatsoftware

componentscan do rather than how they do them. Thus, the

extensible operating systemsresearchcommunity has turned its

attention towardsexploiting component technology in thedesign ofoperating systems. Componentscan form the building blocks of

operating systems. Moreover, component frameworkssuchas CORBA

[17], COM [3], and JavaBeanshave proven to simplify development,

promotereuse, reducedevelopment time, easemaintenance,

promotescalability, andlead to greaterstabil ity androbustness [26,

13].

Thisarticledescribesrecent efforts in this fieldandcompares two

new component based operating systems, namely, Go! [13]and

Pebble [7]. Thechoice of these two ismotivated by their popularity in

current literature, and the fact that they are products oflessons

learned from previously related projects. Thus they could besaid to

represent the progressmadeso far.


5/26

Related Work

In Smalland Seltzer's paper [24], they havemadeacomparison of

operating systemextension technologies. In what follows, wediscuss

a few recent extensible operating system projects. We organize ourdiscussion along thelines of Clarkeand Coulson'sclassifications [ 4]

presentedearlier.

Build-Time Extensible Systems

Most operating systems we know suchas Microsoft Windows

ME/9x/2000, Unix, Linux, etc. fall in thiscategory, since their kernels

can all beextended by anyone by installing some patch or bymodifying thesourcecodesand then rebuilding. In eithercase, these

systems wouldalmost alwaysrequireareboot before thesechanges

can takeeffect. However, thereare times when rebooting is

unacceptable. In suchcases, one of the operating systemsdiscussed

in next threesectionsmight be the way to go.

Library Extensible Systems

Spring [16] isacomponent-based, multithreadedmicro-kernel

distributed operating system that is binary compatible with Unix,

using a Unixemulation subsystem. Themain features of Spring

include:

y use of Interface Description Language (IDL) to definestronginterfacesand thuslanguage independence

ymicro-kernelarchitecture wherein most of thesystem isimplementedas object managers (servers) running in non-

kernelmode often in separateaddressspaces

y server-based orserverless objects; nucleussupports thedomains (processes), threads, anddoorsabstractions


6/26

y provision ofcross protection domain calls (object invocations)viadoors; provisions ofsecurity throughacombination of

accesscontrollists (ACLs) andsoftwarecapability mechanisms

y unixemulation provided throughan emulation subsystemimplementedasan object manager

The Exokernel [6] project aimsat exterminating all operating system

abstractions. The Exokernelarchitecturedefinesaminimal nucleus

that merely provides protection over barehardware. This

demonstratesavery good performance. Common abstractionscan be

implemented in userspace, and overall the Exokerneldesign

illustrates themerits ofminimalismandsimplicity.

Reflectively extensible systems

Apertos [28] isadistributed object-oriented operating system that is

based on areflectivearchitecture. Thereflection follows froman

object/meta-object separation. Each object isassociated withaset of

meta-objects that define the object'ssemantics. Thisset ofmeta -

objects iscalledameta-space. Eachmeta-object, being an object

too, isalso associated withameta-space. This way, wehaveameta-

hierarchy. Theessential thing is that objectscan change the

composition of theirmeta-spaces, and thusmodifying their

semantics. This ways new semanticsand behaviorcan replace old

ones in thecomponents of the operating system.

Merlin (now renamed to Self/R) [5] isan object-oriented operating

systemdeveloped using the Self programming language. Merlin is

based on areflectivearchitecture that isvery similar to that of the

Apertos operating system. It has thesame object/meta-space

association. However, Merlin differs from Apertos in the

implementation of itsmeta-spaces. We will not go into thedetails of

thisdifferencehere, but interestedreadersmight want to consult De


7/26

Assumpo and Kufuji's paper [5] for thedetails. Merlin achieves

extensibility in thesamemanneras Apertos.

The CHEOPS operating system [21] isan extensible operating system

that usesreflection foradaptability andextensibility. A Class ObjectManager (COM) manages theloading, removal, andexchange of

components. Componentscan bedynamically added, removed, and

exchanged thanks to a threelevelmeta-modeling architecture where

eachclass introduced to thesystemhasaclass object andaclass -

object-class. Thesystemalso maintainsmeta-level information such

asavailableclasses, theclasshierarchy, etc.

Dynamically extensible systems

SPIN [2]supportsextensibility by allowing modules to bedynamically

added to the kernel. Protection is based on the use ofa type-safe

language (Modula-3), compile-timechecks, anddynamicreference

resolution. Thecore SPIN systemservices weredesigned with

extensibility in mind;extensions (written in a type-safelanguage)

extend thecore functionality to specializesystemservices to

individualapplications. Extensions to SPIN are written in Modula-3.

Modula-3 forcesextensions to adhere to interfaces, thereby enforcing

modularity. Thissafety system is implemented throughcompilation

andrun-timechecking features. To achieve optimal performance,

extension code isdynamically linked within the kerneladdressspace,

so as to avoid kernelcrossingsduring kernel to extension

communication. Thesafety ofextensions in SPIN dependsextensively

on the use of the Modula-3 language. Althougha number ofargumentsare given as to why thislanguage isappropriate, efficient,

andeasy to use, the fact stillremains that a great proportion of

existing code is not in Modula-3. Specialization of operating system

code to suit applications isclearly beneficial. Issuesrelevant to

specialization areefficiency, safety, and flexibility. SPIN demonstrates


8/26

that efficiency can beachieved throughco-location, and flexibility

throughcarefuldesign. Safety can also beachieved, but at thecost

of imposing limitations on thelanguage usedand/or theextension

code's functionality.

VINO [23] isadownloadablesystem that usessand-boxing to

enforce trust andsecurity. Extensionsare written in C++ andare

compiled by a trustedcompiler that prevents theextension from

accessing text ordata outside its own addressrange, except for

permittedentry points. This trustedcode is then downloaded into the

kernel. Themajorstrengths of thismethodare that performance is

only slightly worse than unprotected C++ andextensionscan be

implemented in conventionallanguages. To facilitate graceful

recovery froman extension failure, VINO runseachextension in the

context ofa transaction. If theextension fails ormust beaborted

(because it ismonopolizing resources), the transaction mechanism

undoesallactions taken by theextension. VINO extensionsare

bound withresources, including bothapplicationsand files, so

extensions persist acrosssystemrebootsand kernel upgrades. The

VINO kernel isconstructed fromacollection of objects. Extensibility isprovided by replacing or overloading specificmethods on those

objects, resulting in alimited proceduralextensibility model.

Moreover, VINO objectsaredesignedso that all policy decisionsare

implemented in simplemember functions that can bereplaced or

overloaded.

MMLite [11]does not definea kernelentity, norany fixedcore

abstractions. Abstractions that are typically designed into an

operating system, suchasvirtualmemory management and inter-

processcommunication, areloadablecomponents in thissystem.

MMLiteemploysa unified programming model that is independent of

the privilege issue (i.e., no uservs. kerneldistinction). Mutation

makes possibleextensibility down to the granularity ofamethodcall.


9/26

Mutation allowsmethods to bedynamically replacedat clean points.

The Microsoft COM Model isemployedand IPC can be LPC orRPC

depending on thelocation of thecallerand thecallee (transparent

remote invocation). The focus of the MMLitedesign is on adaptability,

minimalism, andreusability.

DEIMOS [4]defines no kernelentity. However, the Configuration

Manager (CM) serves the purpose ofamicro-kernel guarding access

to sharedhardwareresources, more orlesslike the Exokernel

architecture. An abstraction calledmodules, similar to components, is

the unit ofextensibility in DEIMOS. Distinction ismade between core

modules, whichhave privilegestatus, andapplication modules. All

modulesareloadableand unloadable including the CM module. A

hardware protection mechanism is used to protect the DEIMOS core

modules, but currently application modulesare not protected from

each other.

The next two sectionsdescribe two recent component-based

operating systems that haverecently gainedattention ofresearchers,

e.g. Pebbleand Go!.

Pebble

Pebble [7] isa new operating systemdeveloped for MIPS-based

processorsat the Information SciencesResearch Centerat Bell-Labs.

Pebble isdesigned for flexibility, safety, andhigh performance.

Pebblesupportscomposing an operating system out of fine -grained

components, eachrunning within its own protection domain (PD). A

PD issimply an execution environment, made up ofaset of pages

(represented by a page table) andaset of portalsstored in the PD's

portal table. The portal isaconceptual generalization ofan interrupt

handler, inherited from the SPACE operating system [19]. In Pebble,

PDsmay sharea portal tableas wellas pages. The key philosophy

behind thedesign of Pebble is in making the nucleusaslean as


10/26


11/26

componentsare trusted, so they may be grantedlimited privileges

not afforded to application components.

Pebblecan intercept callsmade by clients to itsserversand then

interposemodifiablecode operations of theserver, enforcesafetypoliciesandahost of other functions. This is possible becauseeach

portal invocation involves generation of portal-specificcode. This

mechanismallows for the optimization of PD traversalcodes on a per

portal basis. And this is the basis of Pebble's flexibility anddynamic

extensibility:custom portal traversalcodes (Figure 1).

Go!

Go! [13] isa new component-based operating systemdevelopedat

the Department of Computing at City University, London. Go! does

away withadual processormodeaddressspace: Allcomponents,

eithersystemcomponents orapplication components, (together with

an ORB) run in privilegedmode. Most componentsare prevented

fromcontaining instructions that would be illegal in usermode,

throughamechanismcalledcode scanning. When loading a

component, itscodesection isexamined for instructions it is notsufficiently privileged to execute. Only when acomponent is free of

suchcode is it allowed to run.

The ORB only handlescomponent lifetimemanagement and inter-

component method invocation andreturn (Figure 2). It is

application-levelcomponents that managedevices, paging and

handle interrupts, etc.


12/26

Figure 2: Inter-Component Communication is brokered by the ORB

in Go! [8].

The only implementation of Go! availableat the time of writing usesa

segmented pagedmemory scheme on the Intel IA32-basedmachines

[12]. The orthogonalcombination ofsegmentation with paging has

well known advantages [25]. Forexample, an address generated by

an instruction (known asalogicaladdress) isconverted into alinearaddress using thesegmentation model. Thelinearaddress is then fed

through the paging hardware to generatea physicaladdress [14].

Pebble vs. Go!

In thissection, Pebbleand Go! are compared based on the following

features:

y protection levelsy protection mechanismy interrupt handlingy extensibilityy multithreadingy performance


13/26

y open-sourcedesign

Protection Levels

In Pebble, only the nucleusruns in privilegelevel 0, whileall other

componentsrun in userspace. In Go!, however, everything runs in

privilegelevel 0.

Protection Mechanism

Protection in Pebble ismaintained by thehardware paging protection

mechanism. A threadexecuting within a PD may not access pages

outside the PD's page table. If it must, then it has to go through the

portalmechanism. The portalmechanism willmigrate 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 sucha

portal traversalhappens, the threadloses itsaccess to itssource PD

until it returns. Therearecases when the portalcode would

manipulate the portal table of the invoked PD and/or invoking PD to

give the threada window into theaddressspace of itssource PD.This window isshut assoon as the threadreturnshome.

Sinceallcomponents in Go! run at privilegelevel 0, they inherently

haveaccess to allmemory addresses. This is possible because

hardwarememory protection schemesallow a piece ofcode to access

segments/pages for which itsclearancelevel (privilegelevel) islower

than orequal to. Thus, hardwarememory protection is not possible

sinceevery piece ofcodehas themost privilegedclearancelevel(level 0). Go! ensurescodesdon't accessmemory locations they are

not authorized to by employing code scanning.

Interrupt Handling


14/26

Pebblehides thedetails of interrupts fromhigher-levelcomponents

and uses only semaphores forsynchronization. Any interrupt is

caught in the nucleus by ashort trampoline function [7] that merely

invokes theappropriate portal. It obtains this portal from the portal

table of theactive thread's PD. Essentially, the nucleusdelegates the

interrupt handling to a portal. The invoked portal will then invoke the

interrupt dispatcherserver. The interrupt dispatcherdetermines the

source of the interrupt and performsa V operation on thesource's

semaphore. Typically, a thread wouldalready be waiting on that

semaphore. This isan application of thechain-of-controldesign

pattern.

In Go!, on the otherhand, the ORB has no businesshandling

interrupts. Application levelcomponentscan handle interrupt since

they also run in themost privilegedmode. Typically, an interrupt

handlercomponent will be installed. Here, no modeswitching is

required whichspeeds up interrupt handling tremendously.

Extensibility

The units ofextensibility in Pebbleare the user-levelcomponents.

Extensibility can beachievedeither by adding orreplacing a user -

levelcomponent orvia portal interposition. A wholelibrary operating

systemmay belayered on top of Pebble using thismechanism.

In Go! extensibility isalso achieved by installing a new component or

by replacing an existing one. Go!, like Pebble, can also beextended

by installing alibrary operating systemcomponent on top of which

existing binaries that areexecutable (eg. Exokernel [6]). Multiple

library operating systemsmay coexist.

Multithreading


15/26

Pebble is inherently multithreaded, with the threadabstraction being

part of thesystem. However, this is not thecase for Go!. The Go!

ORB has no notion of threads. However, aservercomponent may

implement a threading model, andapplication components needing

thread functionality may invoke theservices ofsuchacomponent.

Multiplesuch threadmanagercomponentsmay coexist, each

implementing thesame ordifferent threading model.

Performance

Owing to a number ofconstraints, theauthor was unable to compare

the performancelevels of both operating systems. Currently, the only

implementation of Pebble we know ofruns on a MIPS-basemachines,while Go! runs on Intel IA32-basedsystems. Portsare, however,

planned for bothsystems [7, 14]. However, benchmark results,

availableat the Go! Homepage [9]suggest that Go! is better in

performance.

Open-source Design

According to information on the Pebblehomepage [18], itssourcecode willsoon bemadeavailable for non-commercial uses only. On

the otherhand, Go! is freeand open-sourcesoftware. It carries the

GPL license. Go! isaccessible 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 systemsadopt thesamesoftware

engineering paradigm (component technology), they belong to

different operating systemdesign paradigmsandrepresent markedly

different kernelsizes.


16/26

Whileemploying different mechanisms, both Pebbleand Go! are

dynamically adaptablesystemsandhave both attempted to

implement minimalsystems.

Pebble, on the onehand, takesa well-known and well-testedparadigmastep further, with fewerrisks. Go! ismoreadventurous

anddrastic in itsapproach. Although the Go! design isappealing in its

simplicity, its protection model isdifficult to provecorrect.

I expect futurecomponent-basedsystems will takedynamic

extensibility, minimalism, safety, andsimplicity to even greater

extremes.

Glossary

ACL - Acronym for Access Control List. A database that lists the valid

users of thesystemand thelevel ofaccess they have been granted.

Adaptability - Ability to adapt to changesay through graceful

degradation, rather than abruptly crashing.

Address space - Therange ofmemory locations that available to acomputer program.

Admission testing - A mechanismemployed in RTOS's where the

schedulerchecks whether there isstillsufficient resourceavailable to

run a task. It startsexecuting the task only if thereareenough to run

it to completion without missing itsdeadline.

Application-level - A privilegelevel forapplications that run in userspace, which usually restrict them fromdealing directly with the

hardware orencroaching into anotherapplication'saddressspace.

COM - Acronym for Component Object Model. A standarddeveloped

by Microsoft Corporation that enablesconforming objects to


17/26

communicate witheach othereven if the objectshave been created

using different programming languages.

Configurability - Theability to configurean operating system (at

compile, link, ordistribution time) to take on different personalities

CORBA - Acronym for Common Object Request Brokerage

Architecture. A middlewarestandard that enables objects to

communicate witheach other in a way that is platform- and

programming language-independent.

Distributed operating system - A common operating system

shared by a network ofcomputers. It will typically providessupportfor IPC, processmigration, mutualexclusion, and the prevention or

detection ofdeadlock.

Dynamism - Thecapability to change the implementation of

components without shutting themdown. Also known as'hot-

swapping'.

Extensibility - Ability to extend the kernel withcustomservices (or

new abstractions) not built into it out-of-the-box.

Extension code - Code that isloaded into the kernel in an extensible

operating system.

Flexibility - Thisrefers to theability ofasingle operating system to

present different views of itself to concurrently executing

applications, andchange the operating system's behavior

dynamically.

Garbage-collection - A process by whicha program goes through

memory, decides which information stored there is no longer needed,

and frees thememory address they occupy forreuse.


18/26

GPL - Acronym for General Public License. An open-sourcesoftware

licensedeveloped by the Free Software Foundation (FSF) that grants

licensees theright to copy, examine, andmodify thesourcecodeas

long assubsequent distributionsextend thesame privileges to new

recipients.

Hardware Protection - Hardwaremechanisms whichensure that

task cannot accesseach other'saddressspaces.

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

microprocessors.

I

nterface - A specification of theset ofservices that acomponentcan provide.

Interrupt - A signal to themicroprocessor indicating that an event

has occurred that it needs to attend to. When an interrupt is being

occurs, processing issuspended in a way that it can beresumed.

Interrupt handler - A routine, usually part of the operating system,

that executes when an interrupt occurs.

Java bytecode - A compiled Javacode withextension .class that can

beexecuted by the Java interpreter, the JVM.

JavaBeans - A component architecture for Java programs that

enables Java programmers to package Java programs in acontainer

for increased interoperability with other objectsand improved

security.

JVM - Acronym for Java Virtual Machine. A Java interpreterand

runtimeenvironment for Javaapplications.

Kernel - Thecrux ofan operating system. It is themost heavily used

part of the operating system. The kernel is often permanently


19/26


20/26

ORB - Acronym for Object Request Broker. A object busconnecting

different components by forwarding operation invocations fromclient

to servercomponents. Whiledoing this, it transparently handles

nameresolution, typechecking, component instantiation and

destruction, etc.

Paging - Transfer of pages between main memory andsecondary

memory.

Privilege levels (PL) - A set oflevels that characterizes instructions

and processes in sucha way that processescan execute only those

instructions they areauthorized to. Privilege Level 0 means that the

programcan executeall CPU instructions. This the PL the kernelhas.Other programshavehigher PLs. Thelower the PL is, themore the

program isallowed to do. Programsare only allowed to call functions

whichhave thesame orlower PL.

Privileged mode - The processorexecution mode in which the

kernelrunsand privileged instructions (suchasaltering acontrol

register) can beexecuted. Also called thekernel mode.

Process - A program in execution.

Processor mode - Any ofaset ofexecution modes in which the

processorruns. Eachmodehasaset of instructions that it isallowed

to execute.

Protection domain - A program'sexecution environment that is

usually protected by hardware protection mechanisms.

Reflection - Ability to discover information at runtime.

RTOS - Acronym forreal-time operating system. An operating

system that guaranteesacertain capability within aspecified time

constraint.


21/26

Sand-boxing - A scheme forensuring safety in an (say in an

extensible operating system) by limiting therange ofaddress the

codecan reference, so that it does not get to cause unexpected

harm.

Scheduler - An operating systemcomponent that selects tasks or

jobs that are to beexecuted.

Segmentation - Thedivision ofa program orapplication into

segmentsas part ofavirtualmemory scheme.

Semaphores - An integervalue used forsignaling among processes.

Only three operationsmay be performed on asemaphore, all ofwhichareatomic: initialize, decrement, and increment.

Synchronization - Situation in which two ormore processes

coordinate theiractivities based on acondition.

Thread - A sequence ofcontrol within a process.

User mode - The processorexecution mode in which privileged

instructions (suchasaltering acontrolregister) cannot beexecuted.

User space - Therange ofmemory addresses that non-kernel

programsareallowed to use in conventional operating systems.

Virtual memory - Harddisk space that is usedasan extension for

theRAM.

References

1

Back, G., P. Tullmann, L. Stoller, W. C. Hsieh, and J. Lepreau,

"Java Operating Systems: Design and Implementation,"

echnicalReport UUCS-98-015, University of Utah, August

1998.


22/26

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 ACMSymposium onOperating 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 DistributedSystems(ICCDS'98), Annapolis MD, USA, May 1998.

5

De Assumpo Jr., J.M. and S.T. Kufuji. Bootstrapping the

Object-Oriented Operating System Merlin: Just Addreflection.

Technical report, Laboratorio de Sistemas Integraveis,

University of So Paulo, Brazil, 1994

6

Engler, D. R., M. F. Kaashoek, and J. OToole. Exokernel: AnOperating System Architecture for Application-LevelResource

Management. In Proceedings of the Fifteenth ACMSymposium

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 Pebblecomponent-based operating

system. In Proceedings of the 1999 USENIXTechnicalConference, 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


23/26

AnnualTechnology 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 ACMSIGOPS

European Workshop, pp. 6-17, ACM Press, New York, 1998.12

Law, G. and J. McCann, 26 bit Selections on IA32. In EWOOOS

atECOOP2000.

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

ACMSIGOPSEuropean Workshop, 2000.

15

Messer, A. and T. Wilkinson, Components for Operating System

Design, In Proceedings of the International Workshopon Object

Orientation in Operating Systems (IWOOOS96), 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,


24/26

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.htm18

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 Workshopon 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 foran Adaptable Object-Oriented Operating System Based on C++. ECOOPWorkshops

1997, pp. 515-522.

22

Seltzer, M., Endo, Y., Small, C., Smith, K., "An Introduction to

the Architecture of the VINO Kernel". HarvardUniversity

ComputerScience TechnicalReport 34-94, 1994.

23

Seltzer, M., Y. Endo, C. Small, and K. Smith, Dealing withDisaster: Surviving Misbehaved Kernel Extensions. In

Proceedings of the 2ndOSDI Conference, pp. 213-227 (1996).

24


25/26

Small, C. and M. Seltzer, "A Comparison of OS Extension

Technologies," In Proceedings of the 1996 USENIXTechnical

Conference, San Diego, CA, Jan. 1996, pp. 4154.

25

Stallings, W. Operating Systems: Internals andDesignPrinciples. 4th Ed. Prentice-Hall. 2001.

26

Stankovic, J. A. VEST: A Toolset of Constructing and Analyzing

Component Based Operating Systems for EmbeddedandReal-

Time Systems. Universityof Virginia TechnicalReport, July

2000.

27

Wilkinson, T. and K. Murray. "Extensible, Flexibleand Secureservices in Angel, asingleaddressspace -operating system." In

International Conference on Algorithms andArchitectures for

ParallelProcessing (ICA3PP), pages 755-758, Brisbane,

Australia, April 1995. IEEE.

28

Yokote, Y. The ApertosReflective Operating System: The

Concept and its Implementation. OOPSLA 1992, pp. 414-434

Biography

Raimi Rufai ([email protected]) isaResearch Assistant at King Fahd

University of Petroleum & Minerals (KFUPM) in Dhahran, Saudi

Arabia. Heholdsa Bachelors Degree in Computer Science from

University of Ilorin, Nigeria. He iscurrently pursuing his MS degree in

Computer Scienceat KFUPM. His interestsare in SoftwareReuse,Software Metrics, Design Patterns, and Operating Systems.

Theauthor wishes to thank King Fahd University of Petroleum &

Minerals for theirsupport in thestudies that produced this work. He


26/26

Documents

Comparing the Architectures of Component