Transcript Macro vs Microkernels

Macro- vs. Micro- Kernels
Matthew Fluet
CS614 – Advanced Systems
April 5, 2001
Macro-Kernel OSs

Examples




Traditional UNIX
VMS
OS is implemented in “one piece”
Knowledge about the basic system
structure is spread throughout the
operating system
Micro-Kernel OSs

Examples




Mach
Chorus
Amoeba
OS is implemented in “separate pieces”


Kernel controls the basic hardware resources
Services implement the unique characteristics of
an OS environment
Mach


Carnegie Mellon University: 1985 – 1994
Portions incorporated into a number of
commercial OSs




NeXT OS and Mac OS X
DEC's OSF/1 for the DEC Alpha
IBM's OS/2 for the RS6000 based machines
Development continuing in University of
Utah's Flexmach project and the Free
Software Foundation's HURD system
Mach – Goals





Support for multiple threads of control within
a single address space
An extensible and secure interprocess
communication facility
Architecture independent virtual memory
Integrated IPC/VM support
Hooks for transparent shared libraries to
provide binary compatibility with existing OS
environments
Mach – Abstractions




Task: an execution environment in
which threads may run
Thread: a basic unit of CPU utilization
Port: a communication channel that
supports send and receive
Message: a typed collection of data
objects used in communication between
threads
Mach – Tasks and Threads



Tasks are related by a tree structure of task
creation operations
Regions of virtual memory can be marked as
inheritable read-write, copy-on-write, or none
Parallelism can be achieved in three ways



A single task with many threads executing in a
shared address space
Many tasks related by task creation that share
restricted regions of memory
Many tasks communicating via messages
Mach – Virtual Memory

Handle page faults and page-out data
requests outside the kernel



VM objects are represented as communication
channels
Kernel sends message to a pager task
Flexibility allows efficient implementations




File systems
Databases
Dynamic encryption and/or compression
Network shared memory
Mach – IPC



Ports and messages are used to provide
location independence, security, and
data type tagging
Ports can have any number of senders,
but only one receiver
Messages have fixed length headers
and a variable sized collection of typed
data objects
Mach – Networking


Kernel provides no mechanism for IPC
over a network
Network Servers: user-level tasks that
allow transparent IPC over a network

Network servers act as local
representatives for tasks on remote nodes
Mach – OS emulation


Server tasks run on top of the kernel
Multithreaded UNIX Server


A monolithic kernel run as a user program
Multiserver UNIX

A collection of servers providing UNIX
functionality
Mach – Servers

Examples








Name Server
Task Manager
Authentication Server
Network Server
UNIX File Server
NFS Server
UNIX TTY Server
UNIX Pipe Server
Amoeba

Vrije Universiteit and Centrum voor
Wiskunde en Informatica: 1983 - 1996
Amoeba – Goals




Distribution – connecting together many
machines
Parallelism – allowing individual jobs to
use multiple CPUs easily
Transparency – having the collection of
computers act like a single node
Performance – achieving all of the
above in an efficient manner
Amoeba – Objects

An object is conceptually an abstract
type



Software and hardware objects
Each object managed by a server process
to which RPCs can be sent
A capability is a 128-bit value
Server Port Object # Rights Check Field
48
24
8
48
Amoeba – Remote Operations

Primitives




get_request(req_hdr, req_buf, req_size)
put_reply(rep_hdr, rep_buf, rep_size)
do_operation(req_hdr, req_buf, req_size,
rep_hdr, rep_buf, rep_size)
Return status



Request delivered and executed
Request not delivered or executed
Status unknown
Amoeba – Threads



All threads in a process share the same
address space
Threads can (optionally) synchronize
with mutexes and semaphores
Threads are scheduled by the process
Amoeba – Servers

Examples

Memory Server & Process Server



Bullet Server


Segment: a contiguous area of memory with a capability
Process descriptor: a data structure that provides
information about a stunned process
Implements a file system
Directory Server

Provides a mapping of names (ASCII strings) to 128-bit
capabilities for access to the file system
Ameoba – WANs




Domain: an inter-connected collection
of local area networks
Broadcasts limited to a single domain
Processes publish services outside their
domain by using the Service for Wide
Area Networks (SWAN)
Server and client agents coordinate
between domains
Amoeba – OS Emulation


UNIX emulation
Session server provided to handle state
information and handle fork and exec
Chorus


INRIA: 1979 – 1986
Chorus systèmes: 1987 – 1991
Chorus – Goals



High-level coupling of applications
Gradual on-line evolution
Straightforward underlying architecture
which allows the modularity of the
application to be mapped onto the
operational system and which conceals
unnecessary details of distribution from
the application
Chorus - Abstractions





Nucleus: kernel that manages the exchange
of messages between ports attached to
actors
Actor: an address space with components in
both user and system space
Threads: one or more in each actor
Ports: global unique identifiers attached to an
actor for exchange of messages by IPC
Port Groups: provide multicast capabilities
Chorus - Nucleus


At the lowest level, manages the local physical
resources of a site
At the highest level, provides a location independent
IPC mechanism
Chorus – Actors

Defines a protected address space, split into
user address space and system address space




System address space on a site is identical for all
actors on a site
Restricted access to system address space
An actor is tied to one site and all threads of
an actor are executed on that site
A site failure leads to the complete crash of
its actors
Chorus – Ports and Messages


Message: a contiguous byte string logically
copied from sender’s address space to the
receiver’s address space
Ports: represents both an address and an
ordered collection of unconsumed messages



Attached to one actor at a time
Can migrate from one actor to another
Port groups
Chorus – IPC and RPC

IPC: asynchronous message sending



Client is blocked only during local
processing
No guarantee that the message will be
received
RPC: synchronous remote procedure
call
Chorus – VM management

Segment: the unit of exchange between VM
system and data providers



Global object with capabilities
Managed by system actors called mappers
Regions: division of an actor’s address space

Contains a portion of a segment mapped to a
given virtual memory address with specified
access rights
Chorus – Networking

Kernel support for reconfiguration



Port groups
Port migration
Network manager



Remote IPC and RPC
Locating distant ports
Remote host failure handling
Chorus - Subsystems


Sets of actors that export a unified API
UNIX subsystem
Micro-Kernel OSs
Mach
Tasks/Actors
Memory
inheritance
Amoeba
Chorus
Process
migration
Tied to a site
Ports
Capabilities
Port groups;
Port migration
Virtual Memory Pagers
Segments
(no swapping
or paging)
Segments,
mappers,
regions
Networking
Kernel support; Limited kernel
support
Group comm.
No kernel
support
Criticisms and Questions


Is there a significant advantage in using
a micro-kernel design if one only
implements a UNIX emulation server?
Is completely transparent remote IPC
and RPC desirable?

How about transparency of communication
over a LAN vs. over a WAN?
Philosophy - IPC



Micro-kernel applications use crossaddress space IPC to interact with
traditional OC services
System call is faster than a crossaddress space IPC
But, absolute difference has reached
the point where it can largely be
ignored
Philosophy – IPC (cont.)




IPC has gotten faster faster than the
rest of the OS
Performance is dominated by caches,
not address spaces
All data does not need to be marshaled
through the kernel
All services do not need a hardware
firewall
Implementation – Default MM

Implementation of the default memory
manager for Mach 3.0 that resides
entirely in user space


Handles all paging traffic to backing
storage
Uses a small set of kernel privileges to lock
itself in memory and prevent deadlock
Implementation – Default MM

Requirements for the default memory
manager




The default memory manager must be resident
All pages moving between the kernel and the
default memory manager must remain resident
It cannot block to wait for more physical memory
It cannot block to wait for the file system to
allocate temporary disk storage, since the file
system itself may be pageable
Implementation – Default MM

Required extending the kernel interface
with two system calls



Lock a specified range of virtual addresses
for the task into memory
Permanently acquires a kernel stack for the
thread
Bypass the disk allocation problem by
using a pre-specified list of disk blocks