Transcript ppt

Extensibility, Safety and Performance in
the SPIN Operating System
Brian Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun Sirer,
David Becker, Marc Fiuczynski, Craig Chambers, Susan Eggers
Presented By
Ninad Palsule
Motivation
DBMS



General purpose OS
Specialized OS
Application needs a
resource control
–

Ex. DBMS
Hard: Support
specialization in
general purpose OS
User
2
1
Kernel
Data page buffer
Storage
Log page
Why it is hard?
Ref: Fig from presentation prepared by Author from
http://www-spin.cs.washington.edu/
SPIN

Design Goals
–
Extensibility

–
Safety

–
Incremental changes
Correctness
Good performance

Efficiency
SPIN

Approach
–
–

Language and compiler support
Runtime facility
Techniques
–
Co-location


–
Enforced modularity




–
Modula – 3
Compiler enforce interface between modules
Can’t access memory or execute privileged instruction unless access given through interface
Modularity enforced by the compiler enables modules
Logical protection domains

–
Requires dynamic linking
Provides low cost communication
Dynamic linker resolve code in different logical protection domain
Dynamic call binding

System Events
Extensibility
Extension model

Property of Extension
–
–
–



Easy to apply
Transparent
Efficient
Dynamically linked to Kernel address space
Provide controlled communication between
Extension and Base system
Extensions defined in terms of Event and Handler
Extension model





Event raised
Dispatcher call guards and
handlers
Evaluating guards
If guard true then call
handler
Safety issues
–


Access Control
Denial of service
–
–
Ref: Fig from paper 2 in Reference
Type checking
Runaway handlers
Too many handlers
Example: System call
Ref: From presentation prepared by Author of paper 2.
Programmer’s view
Ref: From presentation prepared by Author of paper 2.
SPIN structure
Ref: Fig from presentation prepared by Author
from http://www-spin.cs.washington.edu/
Application: Video system components
Ref: Fig from Author presentation from http://www-spin.cs.washington.edu/
Safety
Modula – 3 support for SPIN

Type Safety
–
–
Array index checks (static & dynamic)
Pointer-safe casting

“VIEW” used to safe cast
–
–

Isolation of untrusted code
–
Terminating untrusted code

–
Implicit exception for unhandled exception
Enforce modularity
–

“EPHEMERAL” procedure tag for killable procedures
Isolating errors in untrusted code


Size of input should match with typed structure
Alignment should match
Interface, Modules and procedures
Automatic storage management
Protection model



Control set of operations on resource
Conventional OS uses Address space as a
protection model
SPIN
–
–
Capabilities
Protection domain
Capabilities






Implemented using pointers
Pointer is a reference to block of memory whose
type is declared within interface.
Externalized Reference before sending to user
space
Unforgeable reference to resources (system object
and interfaces)
Extension reference resources for which they have
valid access
Interfaces protected to allow different extensions to
have different views on services
Protection domains


Set of accessible names available for
execution context
Naming and protection interface at level of
language
–

Name ‘c’ is a instance of type ‘Console.T’
Domains can be intersecting or disjoint
Domain interface
Export/Import domain at run-time
Fig from paper [2]
Core Services
Core Services



Manages Memory and Processor resources
Export interfaces for Extensions
Extensible Memory management
–

Three components: Physical storage, Naming(virtual
address) and Translation
Extensible thread management
–
–
–
–
–
Strands – No state, share processor
Application provide its own thread package
Scheduler runs in Kernel
Checkpoint and Resume events
Block / Unblock Events
Performance
Methodology

Comparative study
–
–
–

Hardware
–

SPIN V0.4
DEC OSF/1 V2.1 (Monolithic OS)
Mach 3.0 (Micro-kernel)
DEC Alpha 133 MHz AXP 3000/400 workstation, 64 MB
RAM, 512 KB unified external cache
Tests
–
–
–
Micro benchmarks
End-to-end performance
Networking
Micro benchmark – Protected
communication



NULL procedure call
Protected in-kernel :
SPIN’s cross domain
procedure call
Cross Address space
call: SPIN’s extension
Protected communication overhead in microseconds
Micro benchmark: Thread Management
overhead
Network Latency and Bandwidth
End-to-end performance
Conclusion





It is possible to achieve all three in single OS
(Extensibility, Safety and Performance)
Extend easily with dynamic linking
Use of language and compile with Event facility for
safety
Communication cost is low
Issues
–
–
–
Dispatcher performance?
Does it solve all Safety issues? How do we test
correctness?
Language restrictions, changes in Modula - 3
References
1.
2.
3.
4.
5.
Extensibility, Safety and Performance in the SPIN Operating
System
Brian Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun
Sirer, David Becker, Marc Fiuczynski, Craig Chambers, Susan
Eggers
Dynamic Binding for an Extensible System, Przemyslaw
Pardyak and Brian Bershad
Safe Dynamic Linking in an Extensible Operating System, Emin
Sirer, Marc Fiucynski, Przemyslaw Pardyak, Brian Bershad
Language Support For Extensible Operating System, Wilson
Hsieh, Marc Fiuczynski, Charles Garrett, Stefan Savage, David
Becker, and Brian Bershad
SPIN Operating System web site: Documentation and source
code
http://www-spin.cs.washington.edu/