Kernels
Download
1 / 30

Kernels - PowerPoint PPT Presentation


  • 152 Views
  • Uploaded on

Kernels. Uri Moszkowicz 04/04/2002. Overview. Extensible Aegis,Xok/ExOS SPIN Macro vs micro Amoeba CHORUS Mach. Extensible Kernels. Definition / purpose Can be changed dynamically to meet the needs of an application Previous work

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Kernels' - velma-alexander


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Kernels
Kernels

Uri Moszkowicz

04/04/2002


Overview
Overview

  • Extensible

    • Aegis,Xok/ExOS

    • SPIN

  • Macro vs micro

    • Amoeba

    • CHORUS

    • Mach


Extensible kernels
Extensible Kernels

  • Definition / purpose

    • Can be changed dynamically to meet the needs of an application

  • Previous work

    • Better OS abstractions that give better control to application (previous papers)

  • Implementations

    • User libraries

    • Virtual machines

    • Downloading into kernel


Aegis xok exos
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 exos2
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 exos3
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 exos4
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 exos5
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

Handler

Guards

Application

Capabilities

Resources

Protection Domains


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 kernels1
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
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
Amoeba

  • Objective

    • Illusion of single powerful timesharing machine

  • User has no knowledge of…

    • Where files are located

    • Which processors their programs are running on

    • Etc

  • Organization

    • Based around capabilities as in SPIN



Amoeba2
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


Amoeba3
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
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)


Chorus1
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



Chorus3
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



Chorus5
Chorus

  • Communication

    • Ports can be grouped, allowing for easy implementation of state machine replicas and reconfiguration


Chorus6
Chorus

  • Virtual memory

    • Handled in units of segments by a mapper, allowing for easy use of ports


Chorus7
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
Summary

  • Which is better? A micro or macro kernel? No real good answer

  • Many systems exist which implement both and have been successful

  • Comments?


ad