comparing the architectures of component
TRANSCRIPT
-
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,
-
8/8/2019 Comparing the Architectures of Component
2/26
-
8/8/2019 Comparing the Architectures of Component
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
-
8/8/2019 Comparing the Architectures of Component
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.
-
8/8/2019 Comparing the Architectures of Component
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
-
8/8/2019 Comparing the Architectures of Component
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
-
8/8/2019 Comparing the Architectures of Component
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/8/2019 Comparing the Architectures of Component
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.
-
8/8/2019 Comparing the Architectures of Component
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
-
8/8/2019 Comparing the Architectures of Component
10/26
-
8/8/2019 Comparing the Architectures of Component
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.
-
8/8/2019 Comparing the Architectures of Component
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
-
8/8/2019 Comparing the Architectures of Component
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
-
8/8/2019 Comparing the Architectures of Component
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
-
8/8/2019 Comparing the Architectures of Component
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.
-
8/8/2019 Comparing the Architectures of Component
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
-
8/8/2019 Comparing the Architectures of Component
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.
-
8/8/2019 Comparing the Architectures of Component
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
-
8/8/2019 Comparing the Architectures of Component
19/26
-
8/8/2019 Comparing the Architectures of Component
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.
-
8/8/2019 Comparing the Architectures of Component
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.
-
8/8/2019 Comparing the Architectures of Component
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
-
8/8/2019 Comparing the Architectures of Component
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,
-
8/8/2019 Comparing the Architectures of Component
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
-
8/8/2019 Comparing the Architectures of Component
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
-
8/8/2019 Comparing the Architectures of Component
26/26