Microkernels and L4

Introduction

COMP9242 2006/S2 Week 1

cse/UNSW/NICTA
 W HY M ICROKERNELS ?

M ONOLITHIC KERNEL
 W HY M ICROKERNELS ?

M ONOLITHIC KERNEL :

• Kernel has access to everything

Ü all optimisations possible
Ü all techniques/mechanisms/concepts
implementable
 W HY M ICROKERNELS ?

M ONOLITHIC KERNEL :

• Kernel has access to everything

Ü all optimisations possible
Ü all techniques/mechanisms/concepts
implementable

• Can be extended by simply

adding code
 W HY M ICROKERNELS ?

M ONOLITHIC KERNEL :

• Kernel has access to everything

Ü all optimisations possible
Ü all techniques/mechanisms/concepts
implementable

• Can be extended by simply

adding code

• Cost: Complexity
Ü growing size
Ü limited maintainability

cse/UNSW/NICTA COMP9242 2006/S2 W1 P1

 M ICROKERNEL : I DEA

• Small kernel providing core functionality

Ü only code running in privileged mode

• Most OS services provided by user-level servers

• Applications communicate with servers via message-passing IPC

Application
syscall

user
mode
VFS

IPC, file system

Application UNIX Device File
Server Driver Server
Scheduler, virtual memory kernel IPC
mode

Device drivers, Dispatcher, ... IPC, virtual memory

Hardware Hardware

cse/UNSW/NICTA COMP9242 2006/S2 W1 P2

 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application

Service

Hardware

System: traditional
embedded
 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application

Service

Hardware

System: traditional
embedded
 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application

Service

Hardware

System: traditional
embedded
 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application
Application

OS

Service Service

Hardware Hardware

System: traditional Linux/

embedded Windows
 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application
Application

OS

Service Service

Hardware Hardware

System: traditional Linux/

embedded Windows
 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application
Application

OS

Service Service

Hardware Hardware

System: traditional Linux/

embedded Windows
 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application
Application

OS

Service Service

Hardware Hardware

System: traditional Linux/

embedded Windows
 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application
Application

OS

Service Service

Hardware Hardware

System: traditional Linux/

embedded Windows
 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application Application
Application

OS

Service
Service Service
Microkernel
Hardware Hardware Hardware

System: traditional Linux/ Microkernel-

embedded Windows based
 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application Application
Application

OS

Service
Service Service
Microkernel
Hardware Hardware Hardware

System: traditional Linux/ Microkernel-

embedded Windows based
 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application Application
Application

OS

Service
Service Service
Microkernel
Hardware Hardware Hardware

System: traditional Linux/ Microkernel-

embedded Windows based
 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application Application
Application

OS

Service
Service Service
Microkernel
Hardware Hardware Hardware

System: traditional Linux/ Microkernel-

embedded Windows based
 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application Application
Application

OS

Service
Service Service
Microkernel
Hardware Hardware Hardware

System: traditional Linux/ Microkernel-

embedded Windows based
 T RUSTED C OMPUTING BASE

The part of the system which must be trusted to operate correctly

Application Application
Application

OS

Service
Service Service
Microkernel
Hardware Hardware Hardware

System: traditional Linux/ Microkernel-

embedded Windows based
TCB: all code 100,000’s loc 10,000’s loc

cse/UNSW/NICTA COMP9242 2006/S2 W1 P3

 M ICROKERNEL P ROMISES

• Combat kernel complexity, increase robustness, maintainability

Ü dramatic reduction of amount of privileged code
Ü modularisation with hardware-enforced interfaces
Ü normal resource management applicable to system services

• Flexibility, adaptability, extensibility

Ü policies defined at user level, easy to change
Ü additional services provided by adding servers

• Hardware abstraction
Ü hardware-dependent part of system is small, easy to optimise

• Security, safety
Ü internal protection boundaries
 M ICROKERNEL P ROMISES

!
• Combat kernel complexity, increase robustness, maintainability
K
Ü dramatic reduction of amount of privilegedC
Ü modularisation with hardware-enforcedE
code

C
Ü normal resource management applicable
H interfaces
to system services

I T Y
A L
• Flexibility, adaptability, extensibility

Ü additionalR
E
Ü policies defined at user level, easy to change
services provided by adding servers

• Hardware abstraction
Ü hardware-dependent part of system is small, easy to optimise

• Security, safety
Ü internal protection boundaries
 M ICROKERNEL P ROMISES

!
• Combat kernel complexity, increase robustness, maintainability
K
Ü dramatic reduction of amount of privilegedC
Ü modularisation with hardware-enforcedE
code

C H interfaces
e
Ü normal resource management applicable
Y i b l
to system services

L I
• Flexibility, adaptability, T extensibility x
e
E
Ü policies defined Aat user level,
i
easyn fl
to change
Ü additionalR
w
services provided by, adding servers

• Hardware abstraction s l o
Ü hardware-dependent part of system is small, easy to optimise

• Security, safety
Ü internal protection boundaries
 M ICROKERNEL P ROMISES

!
• Combat kernel complexity, increase robustness, maintainability
K
Ü dramatic reduction of amount of privilegedC
Ü modularisation with hardware-enforcedE
code

C H interfaces
e
Ü normal resource management applicable
Y i b l
to system services

L I
• Flexibility, adaptability, T extensibility x
e
E A n fl
to change IP
C
Ü policies defined
Ü additionalR , i
at user level, easy
c
l o w
services provided by
e
adding servers
s
• Hardware abstraction s 00µ
Ü hardware-dependent part1 of system is small, easy to optimise

• Security, safety
Ü internal protection boundaries

cse/UNSW/NICTA COMP9242 2006/S2 W1 P4

 IPC C OSTS

• First-generation microkernels
Ü Mach, Chorus, Amoeba
 IPC C OSTS

• First-generation microkernels
Ü Mach, Chorus, Amoeba

... were slow...

Ü 100µs IPC
Ü almost independent of clock speed!
 IPC C OSTS

• First-generation microkernels
Ü Mach, Chorus, Amoeba

... were slow...

Ü 100µs IPC
Ü almost independent of clock speed!

• L4 does better
Ü close to hardware cost
Ü 20 times faster than Mach
on identical hardware

cse/UNSW/NICTA COMP9242 2006/S2 W1 P5

 IPC C OST I MPLICATIONS

cse/UNSW/NICTA COMP9242 2006/S2 W1 P6

 L4 IPC

cse/UNSW/NICTA COMP9242 2006/S2 W1 P7

 M ICROKERNEL P ERFORMANCE

F IRST- GENERATION MICROKERNELS WERE SLOW

• Reasons: Poor design [Liedtke SOSP 95]

Ü complex API
Ü too many features
Ü poor design and implementation
 M ICROKERNEL P ERFORMANCE

F IRST- GENERATION MICROKERNELS WERE SLOW

• Reasons: Poor design [Liedtke SOSP 95]

Ü complex API
Ü too many features
Ü poor design and implementation
Ü large cache footprint ⇒ memory bandwidth limited
 M ICROKERNEL P ERFORMANCE

F IRST- GENERATION MICROKERNELS WERE SLOW

• Reasons: Poor design [Liedtke SOSP 95]

Ü complex API
Ü too many features
Ü poor design and implementation
Ü large cache footprint ⇒ memory bandwidth limited

• L4 is fast due to small cache footprint

Ü 10–14 I-cache lines
Ü 8 D-cache lines
Ü small cache footprint ⇒ CPU limited

cse/UNSW/NICTA COMP9242 2006/S2 W1 P8

 W HAT M AKES A M ICROKERNEL FAST ?

• Small cache footprint, but how?

 W HAT M AKES A M ICROKERNEL FAST ?

• Small cache footprint, but how?

Ü minimality: no unnecessary features
Ü orthogonality: complementary features
Ü well-designed, and well implemented from scratch!
 W HAT M AKES A M ICROKERNEL FAST ?

• Small cache footprint, but how?

Ü minimality: no unnecessary features
Ü orthogonality: complementary features
Ü well-designed, and well implemented from scratch!

• Kernel provides mechanisms, not services

 W HAT M AKES A M ICROKERNEL FAST ?

• Small cache footprint, but how?

Ü minimality: no unnecessary features
Ü orthogonality: complementary features
Ü well-designed, and well implemented from scratch!

• Kernel provides mechanisms, not services

• Design principle (minimality):

A feature is only allowed in the kernel if this is required for the
implementation of a secure system.

cse/UNSW/NICTA COMP9242 2006/S2 W1 P9

L4 H ISTORY
 L4 H ISTORY

• Original version by Jochen Liedtke (GMD) ≈ 93–95

Ü “Version 2” API
Ü i486 assembler
Ü IPC 20 times faster than Mach [SOSP 93, 95]
 L4 H ISTORY

• Original version by Jochen Liedtke (GMD) ≈ 93–95

Ü “Version 2” API
Ü i486 assembler
Ü IPC 20 times faster than Mach [SOSP 93, 95]

• Other L4 V2 implementations:
Ü L4/MIPS64: assembler + C (UNSW) 95–97
Ü fastest kernel on single-issue CPU (100 cycles)
Ü L4/Alpha: PAL + C (Dresden/UNSW), 95–97
Ü first released SMP version
Ü Fiasco (Pentium): C++ (Dresden), 97–99

cse/UNSW/NICTA COMP9242 2006/S2 W1 P10

 L4 H ISTORY

• Experimental “Version X” API

Ü improved hardware abstraction
Ü various experimental features (performance, security, generality)
Ü portability experiments
 L4 H ISTORY

• Experimental “Version X” API

Ü improved hardware abstraction
Ü various experimental features (performance, security, generality)
Ü portability experiments

• Implementations
Ü Pentium: assembler, Liedtke (IBM), 97-98
Ü Hazelnut (Pentium+ARM), C, Liedtke et al (Karlsruhe), 98–99

cse/UNSW/NICTA COMP9242 2006/S2 W1 P11

 L4 H ISTORY

• “Version 4” (X.2) API, 02

Ü portability, API improvements
 L4 H ISTORY

• “Version 4” (X.2) API, 02

Ü portability, API improvements

• L4Ka::Pistachio, C++ (plus assembler “fast path”)

Ü x86, PPC-32, Itanium (Karlsruhe), 02–03
Ü fastest ever kernel (36 cycles, NICTA/UNSW)
Ü MIPS64, Alpha (NICTA/UNSW) 03
Ü same performance as V2 kernel (100 cycles single issue)
Ü ARM, PPC-64 (NICTA/UNSW), x86-64 (Karlsruhe), 03-04
Ü UltraSPARC (NICTA/UNSW), 04–??
 L4 H ISTORY

• “Version 4” (X.2) API, 02

Ü portability, API improvements

• L4Ka::Pistachio, C++ (plus assembler “fast path”)

Ü x86, PPC-32, Itanium (Karlsruhe), 02–03
Ü fastest ever kernel (36 cycles, NICTA/UNSW)
Ü MIPS64, Alpha (NICTA/UNSW) 03
Ü same performance as V2 kernel (100 cycles single issue)
Ü ARM, PPC-64 (NICTA/UNSW), x86-64 (Karlsruhe), 03-04
Ü UltraSPARC (NICTA/UNSW), 04–??

• Portable kernel:
Ü ≈ 3 person months for core functionality
Ü 6–12 person months for full functionality & optimisation

cse/UNSW/NICTA COMP9242 2006/S2 W1 P12

 L4 H ISTORY

• NICTA L4-embedded (Nx) API, 05–

Ü transitional API (pre-seL4)
Ü de-featured (timeouts, “long” IPC, recursive mappings)
Ü reduced memory footprint for embedded systems
 L4 H ISTORY

• NICTA L4-embedded (Nx) API, 05–

Ü transitional API (pre-seL4)
Ü de-featured (timeouts, “long” IPC, recursive mappings)
Ü reduced memory footprint for embedded systems

• NICTA::Pistachio-embedded, derived from L4KA::Pistachio

Ü ARM9/ARM11, x86, MIPS
Ü PPC 405, Blackfin under development
 L4 H ISTORY

• NICTA L4-embedded (Nx) API, 05–

Ü transitional API (pre-seL4)
Ü de-featured (timeouts, “long” IPC, recursive mappings)
Ü reduced memory footprint for embedded systems

• NICTA::Pistachio-embedded, derived from L4KA::Pistachio

Ü ARM9/ARM11, x86, MIPS
Ü PPC 405, Blackfin under development

• You’ll be using the (unreleased) N2 API implementation

cse/UNSW/NICTA COMP9242 2006/S2 W1 P13

 L4 P RESENT

• NICTA L4-embedded commercially deployed

Ü adopted by Qualcomm for CDMA chipsets
Ü under evaluation/development for other products at a number of multinationals
Ü about to establish strong presence in wireless and CE markets
 L4 P RESENT

• NICTA L4-embedded commercially deployed

Ü adopted by Qualcomm for CDMA chipsets
Ü under evaluation/development for other products at a number of multinationals
Ü about to establish strong presence in wireless and CE markets

• NICTA spinning out Open Kernel Labs

Ü further development of L4-embedded
Ü professional services for L4 users
Ü commercialisation of present NICTA microkernel research

cse/UNSW/NICTA COMP9242 2006/S2 W1 P14

 L4 F UTURE

• Security API: NICTA seL4

Ü draft published March 06
Ü semi-formal specification in Haskell
Ü “executable spec”: Haskell implementation plus ISA simulator
Ü used for exercising and porting apps
Ü stable API August 06
Ü C implementation end of 06
Ü similar project at TU Dresden: L4sec (draft API Oct 05)
 L4 F UTURE

• Security API: NICTA seL4

Ü draft published March 06
Ü semi-formal specification in Haskell
Ü “executable spec”: Haskell implementation plus ISA simulator
Ü used for exercising and porting apps
Ü stable API August 06
Ü C implementation end of 06
Ü similar project at TU Dresden: L4sec (draft API Oct 05)

• Features:
Ü user-level management of kernel resources (esp. memory)
Ü low-overhead information-flow control mechanisms
Ü suitable for formal verification
 L4 F UTURE

• Security API: NICTA seL4

Ü draft published March 06
Ü semi-formal specification in Haskell
Ü “executable spec”: Haskell implementation plus ISA simulator
Ü used for exercising and porting apps
Ü stable API August 06
Ü C implementation end of 06
Ü similar project at TU Dresden: L4sec (draft API Oct 05)

• Features:
Ü user-level management of kernel resources (esp. memory)
Ü low-overhead information-flow control mechanisms
Ü suitable for formal verification

• Formal verification of L4 implementation: L4.verified project

Ü mathematical proof that implementation matches spec

cse/UNSW/NICTA COMP9242 2006/S2 W1 P15

 P ISTACHIO : S IZE

• Source code:
Ü ≈ 10k loc architecture independent
Ü ≈ 0.5–2k loc architecture specific
 P ISTACHIO : S IZE

• Source code:
Ü ≈ 10k loc architecture independent
Ü ≈ 0.5–2k loc architecture specific

• Memory footprint kernel (no attempt to minimise yet):

Ü using gcc (poor code density on RISC/EPIC architectures)
Architecture Version Text Total
x86 L4Ka 52k 98k
Itanium L4Ka 173k 417k
ARM NICTA 55k 117k
PPC-32 L4Ka 41k 135k
PPC-64 L4Ka 60k 205k
MIPS-64 L4Ka 61k 100k
 P ISTACHIO : S IZE

• Source code:
Ü ≈ 10k loc architecture independent
Ü ≈ 0.5–2k loc architecture specific

• Memory footprint kernel (no attempt to minimise yet):

Ü using gcc (poor code density on RISC/EPIC architectures)
Architecture Version Text Total
x86 L4Ka 52k 98k
Itanium L4Ka 173k 417k
ARM NICTA 55k 117k
PPC-32 L4Ka 41k 135k
PPC-64 L4Ka 60k 205k
MIPS-64 L4Ka 61k 100k

• Fast IPC cache footprint (typical):

Ü 10–14 I-cache lines
Ü 8 D-cache lines
cse/UNSW/NICTA COMP9242 2006/S2 W1 P16
 S IZE C OMPARISON

cse/UNSW/NICTA COMP9242 2006/S2 W1 P17

 P ISTACHIO P ERFORMANCE : IPC

port/ C++ optimised

Architecture optimisation intra AS inter AS intra AS inter AS
Pentium-3 UKa 180 367 113 305
Small Spaces UKa 213
Pentium-4 UKa 385 983 196 416
Itanium 2 UKa/NICTA 508 508 36 36
cross CPU UKa 7419 7410 N/A N/A
MIPS64 NICTA/UNSW 276 276 109 109
cross CPU NICTA/UNSW 3238 3238 690 690
PowerPC-64 NICTA/UNSW 330 518 200‡ 200‡
Alpha 21264 NICTA/UNSW 440 642 ≈70† ≈70†
ARM/XScale NICTA/UNSW 340 340 151 151

†
“Version 2” assembler kernel
‡
Guestimate!

cse/UNSW/NICTA COMP9242 2006/S2 W1 P18

 L4 A BSTRACTIONS AND M ECHANISMS

T HREE BASIC ABSTRACTIONS :

• Address spaces

• Threads

• Time (second-class abstraction in N2 API, to vanish completely)

T WO BASIC MECHANISMS :

• Inter-process communication (IPC)

• Mapping

cse/UNSW/NICTA COMP9242 2006/S2 W1 P19

 L4 A BSTRACTIONS : A DDRESS S PACES

• Address space is unit of protection

 L4 A BSTRACTIONS : A DDRESS S PACES

• Address space is unit of protection

Ü initially empty
Ü populated by mapping in frames
 L4 A BSTRACTIONS : A DDRESS S PACES

• Address space is unit of protection

Ü initially empty
Ü populated by mapping in frames

• Mapping performed by privileged MapControl() syscall

Ü can only be called from root task
Ü also used for revoking mappings (unmap operation)
 L4 A BSTRACTIONS : A DDRESS S PACES

• Address space is unit of protection

Ü initially empty
Ü populated by mapping in frames

• Mapping performed by privileged MapControl() syscall

Ü can only be called from root task
Ü also used for revoking mappings (unmap operation)

• Root task
Ü initial address space created at boot time
Ü controls system resources
Ü non-delegatable privilege (shortcoming of N2 API)

cse/UNSW/NICTA COMP9242 2006/S2 W1 P20

 L4 A BSTRACTIONS : T HREADS

• Thread is unit of execution

Ü kernel-scheduled
 L4 A BSTRACTIONS : T HREADS

• Thread is unit of execution

Ü kernel-scheduled

• Thread is addressable unit for IPC

Ü thread-ID is unique identifier
 L4 A BSTRACTIONS : T HREADS

• Thread is unit of execution

Ü kernel-scheduled

• Thread is addressable unit for IPC

Ü thread-ID is unique identifier

• Threads managed by user-level servers

Ü creation, destruction, association with address space
 L4 A BSTRACTIONS : T HREADS

• Thread is unit of execution

Ü kernel-scheduled

• Thread is addressable unit for IPC

Ü thread-ID is unique identifier

• Threads managed by user-level servers

Ü creation, destruction, association with address space

• Thread attributes:
Ü scheduling parameters (time slice, priority)
Ü unique ID
Ü address space
Ü page-fault and exception handler

cse/UNSW/NICTA COMP9242 2006/S2 W1 P21

 L4 A BSTRACTIONS : T IME

• Used for scheduling time slices

Ü thread has fixed-length time slice for preemption
Ü time slices allocated from (finite or infinite) time quantum
Ü notification when exceeded

• In earlier L4 versions also used for IPC timeouts

Ü removed in N2

cse/UNSW/NICTA COMP9242 2006/S2 W1 P22

 L4 M ECHANISM : IPC

• Synchronous message-passing operation

 L4 M ECHANISM : IPC

• Synchronous message-passing operation

• Data copied directly from sender to receiver

Ü short messages passed in registers
 L4 M ECHANISM : IPC

• Synchronous message-passing operation

• Data copied directly from sender to receiver

Ü short messages passed in registers

• Can be blocking or polling (fail if partner not ready)

 L4 M ECHANISM : IPC

• Synchronous message-passing operation

• Data copied directly from sender to receiver

Ü short messages passed in registers

• Can be blocking or polling (fail if partner not ready)

• Asynchronous notification variant

Ü no data transfer, only sets notification bit in receiver
Ü receiver can wait (block) or poll

cse/UNSW/NICTA COMP9242 2006/S2 W1 P23

 L4 C ONCEPTS : R OOT TASK

• First task started at boot time

• Can perform privileged system calls

 L4 C ONCEPTS : R OOT TASK

• First task started at boot time

• Can perform privileged system calls

• Controls access to resources

Ü threads
Ü address spaces
Ü physical memory

cse/UNSW/NICTA COMP9242 2006/S2 W1 P24

 L4 C ONCEPTS : R OOT TASK

• First task started at boot time

• Can perform privileged system calls

• Controls access to resources

Ü threads
Ü address spaces
Ü physical memory

Physical Memory

cse/UNSW/NICTA COMP9242 2006/S2 W1 P24

 L4 C ONCEPTS : R OOT TASK

• First task started at boot time

• Can perform privileged system calls

• Controls access to resources

Ü threads
Ü address spaces
Ü physical memory

Root Task

Physical Memory

cse/UNSW/NICTA COMP9242 2006/S2 W1 P24

 L4 C ONCEPTS : R OOT TASK

• First task started at boot time

• Can perform privileged system calls

• Controls access to resources

Ü threads
Ü address spaces
Ü physical memory

Driver Driver

Root Task

Physical Memory

cse/UNSW/NICTA COMP9242 2006/S2 W1 P24

 L4 C ONCEPTS : R OOT TASK

• First task started at boot time

• Can perform privileged system calls

• Controls access to resources

Ü threads
Ü address spaces
Ü physical memory
Server Server

Server Server Driver Driver

Root Task

Physical Memory

cse/UNSW/NICTA COMP9242 2006/S2 W1 P24

 L4 C ONCEPTS : R OOT TASK

• First task started at boot time

• Can perform privileged system calls

• Controls access to resources

Ü threads
Client Client
Ü address spaces
Ü physical memory
Server Server

Server Server Driver Driver

Root Task

Physical Memory

cse/UNSW/NICTA COMP9242 2006/S2 W1 P24

 L4 E XCEPTION H ANDLING

• Interrupts

• Page faults

• Other exceptions
 L4 E XCEPTION H ANDLING

• Interrupts
Ü modelled as hardware “thread” sending messages
Ü received by registered (user-level) interrupt-handler thread
Ü interrupt acknowledged when handler blocks on receive
Ü timer interrupt handled in-kernel

• Page faults

• Other exceptions
 L4 E XCEPTION H ANDLING

• Interrupts
Ü modelled as hardware “thread” sending messages
Ü received by registered (user-level) interrupt-handler thread
Ü interrupt acknowledged when handler blocks on receive
Ü timer interrupt handled in-kernel

• Page faults
Ü kernel fakes IPC message from faulting thread to its pager
Ü pager requests root task to set up a mapping
Ü pager replies to faulting client, message intercepted by kernel

• Other exceptions
 L4 E XCEPTION H ANDLING

• Interrupts
Ü modelled as hardware “thread” sending messages
Ü received by registered (user-level) interrupt-handler thread
Ü interrupt acknowledged when handler blocks on receive
Ü timer interrupt handled in-kernel

• Page faults
Ü kernel fakes IPC message from faulting thread to its pager
Ü pager requests root task to set up a mapping
Ü pager replies to faulting client, message intercepted by kernel

• Other exceptions
Ü kernel fakes IPC message from exceptor thread to its exception handler
Ü exception handler may reply with message specifying new IP, SP
Ü can be signal handler, emulation code, stub for IPCing to server, ...

cse/UNSW/NICTA COMP9242 2006/S2 W1 P25

F EATURES N OT I N K ERNEL
 F EATURES N OT I N K ERNEL

• System services (file system, network stack, ...)

Ü implemented by user-level servers

• VM management
Ü performed by (hierarchy) of user-level pagers
 F EATURES N OT I N K ERNEL

• System services (file system, network stack, ...)

Ü implemented by user-level servers

• VM management
Ü performed by (hierarchy) of user-level pagers

• Device drivers
Ü user-level threads registered for interrupt IPC
Ü map device registers

cse/UNSW/NICTA COMP9242 2006/S2 W1 P26