1 / 38

Macro- vs. Micro- Kernels

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

kevyn
Download Presentation

Macro- vs. Micro- Kernels

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Macro- vs. Micro- Kernels Matthew Fluet CS614 – Advanced Systems April 5, 2001

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. Mach – Servers • Examples • Name Server • Task Manager • Authentication Server • Network Server • UNIX File Server • NFS Server • UNIX TTY Server • UNIX Pipe Server

  13. Amoeba • Vrije Universiteit and Centrum voor Wiskunde en Informatica: 1983 - 1996

  14. 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

  15. Server Port 48 Object # 24 Rights 8 Check Field 48 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

  16. 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

  17. 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

  18. Amoeba – Servers • Examples • Memory Server & Process Server • Segment: a contiguous area of memory with a capability • Process descriptor: a data structure that provides information about a stunned process • Bullet Server • Implements a file system • Directory Server • Provides a mapping of names (ASCII strings) to 128-bit capabilities for access to the file system

  19. 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

  20. Amoeba – OS Emulation • UNIX emulation • Session server provided to handle state information and handle fork and exec

  21. Chorus • INRIA: 1979 – 1986 • Chorus systèmes: 1987 – 1991

  22. 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

  23. 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

  24. Chorus - Nucleus • At the lowest level, manages the local physical resources of a site • At the highest level, provides a location independent IPC mechanism

  25. 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

  26. 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

  27. 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

  28. 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

  29. Chorus – Networking • Kernel support for reconfiguration • Port groups • Port migration • Network manager • Remote IPC and RPC • Locating distant ports • Remote host failure handling

  30. Chorus - Subsystems • Sets of actors that export a unified API • UNIX subsystem

  31. Micro-Kernel OSs

  32. 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?

  33. Philosophy - IPC • Micro-kernel applications use cross-address space IPC to interact with traditional OC services • System call is faster than a cross-address space IPC • But, absolute difference has reached the point where it can largely be ignored

  34. 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

  35. 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

  36. 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

  37. 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

More Related