Transcript Macro vs Micro & Extensible Kernels

Kernels
Uri Moszkowicz
04/04/2002
Overview

Extensible



Aegis,Xok/ExOS
SPIN
Macro vs micro



Amoeba
CHORUS
Mach
Extensible Kernels

Definition / purpose


Previous work


Can be changed dynamically to meet the needs of
an application
Better OS abstractions that give better control to
application (previous papers)
Implementations



User libraries
Virtual machines
Downloading into kernel
Aegis,Xok/ExOS


Monolithic = exokernel + user libraries
Exokernel = Aegis (MIPS), Xok (x86)





Securely expose hardware (little abstraction)
Expose allocation (of resources)
Expose names (of physical resources)
Expose revocation (of resources)
User libraries = ExOS

Resource management (ie time-slices)
Aegis,Xok/ExOS
Aegis,Xok/ExOS

Resource allocation


Handled by ExOS, but among libraries
kernel must allocate
Secure bindings performance
considerations


Only at bind time
Hardware, software caching, and
downloading application code
Aegis,Xok/ExOS

Downloading code into kernel




To deal with real-time constraints
Avoids crossing kernel/user boundary and
circumvents resource allocation
Safety limited to code inspection
Resource revocation


For misbehaving applications
Handled by “Abort” protocol
Aegis,Xok/ExOS

Case studies

Dynamic Packet Filter


Dynamic code generated at runtime to classify
packets
Tested at user-level, but more appropriately
downloaded into kernel
Aegis,Xok/ExOS

XN




Provides stable storage
at disk block level
Eliminates need for
fixed partitions
Only provides
protection
C-FFS implemented
UNIX-like file system
SPIN


Monolithic kernel extendable through
modules that can be dropped in
Goals





Co-location (located w/in kernel address)
Modularity
Protection domains (namespace/exports)
Dynamic call binding (event handlers)
Similar to Linux modules + Cyclone
SPIN

Protection for kernel code relies on
type-safe language features of Modula3


Combination of static and dynamic checks
which enforce memory regions and verify
memory references
Applications written in any language
SPIN

Protection model



Resources accessed through capability
pointers located in a table accessible by
both kernel and user
Similar to /proc interface + symbol table
Extension components



Events – announces change in system
Handler – Responds to the event
Dispatcher – Notifies handler of events
filtered by guards (predicates)
SPIN

Overview
Event
Application
Guards
Capabilities
Protection Domains
Handler
Resources
SPIN

Services

Core services


Provides capabilities to manage processor and
memory
Thread management

Can be easily integrated with kernel because
application can drop its own thread package
into kernel
Extensible Kernels

Summary



Goal is to minimize overhead of accessing
resources and provide application ability to
efficiently use and allocate resources
Ultimately, application needs access and
capability to affect resources on a global
scale
Comments?
Macro vs Micro Kernels

The argument


What, and how much, belongs in the kernel?
Philosophy

Micro-kernel



Kernel should be minimal in size, handling basic
operations
Ex: the extensible kernels just described, MACH, OS-X
Macro-kernels

Applications conform to high-level abstractions, knowing
little or nothing about hardware
Amoeba

Objective


User has no knowledge of…




Illusion of single powerful timesharing machine
Where files are located
Which processors their programs are running
on
Etc
Organization

Based around capabilities as in SPIN
Amoeba
Amoeba

System arranged as a combination of
workstations and servers which
communication with simple primitives





Get_request (server ready to accept)
Put_reply (server replying with result of operation)
Do_operation (perform the requested operation)
Kernel handles messaging, scheduling,
memory management
Servers run at user-level and handle
everything else
Amoeba

Servers



Network organized into domains of LANs that
communicate of WANs
Each domain maintains a Service for Wide-Area
Networks server, which maintains a list of
published servers
When a user process needs access to a server, it
accesses the service transparently
Chorus




Another attempt at reorganizing the OS
Like Amoeba, implemented such that the
application knows very little about what is
underneath it
Intended for distributed systems
Unlike Amoeba, Chorus handles real-time
constraints and provides services, such as
traditional operating systems, as subsystems
running on top of Chorus Nucleus (kernel)
Chorus

Basic components



Nucleus – provides generic tools to support
subsystems (ie functions of specific OS); handles
functions such as transparent IPC, VM, real-time
Subsystems - traditional OS functions separated
into groups normally provided by the kernel
Libraries still exist at user level to provide
convenient programming interfaces
Chorus
Chorus

Subsystem components





Actor – encapsulates a set of resources
Thread – sequentially executed code
Port – address used for communication
between actors
Segment – data encapsulation (ie files)
Capability – access control
Chorus
Chorus

Communication

Ports can be grouped, allowing for easy
implementation of state machine replicas
and reconfiguration
Chorus

Virtual memory

Handled in units of segments by a mapper,
allowing for easy use of ports
Chorus

Chorus/MiX – UNIX subsystem
MACH





Another distributed OS based on an
extensible micro-kernel
Similar to other distributed systems where OS
functions are provided above the kernel
Fast IPC, which forms the basis for
communication between all tasks and even
the kernel
As before, implementation exists for
compatibility with UNIX
Basis for many OS, including OS-X, NeXT OS,
and even OS/2
Summary



Which is better? A micro or macro
kernel? No real good answer
Many systems exist which implement
both and have been successful
Comments?