可扩展操作系统

1 .Advanced Operating Systems (CS 202) Extensible Operating Systems Jan, 11, 2016 

2 . OS Structure •  What does OS structure refer to? •  The way the OS software is organized with respect to the applications it serves and the hardware that it manages so that it can meet its goals 2 

3 . Lets start with the basic idea •  All OS’s use “Controlled Direct Execution” –  User programs when scheduled run directly on the CPU –  They don’t have to ask permission to use memory – its virtualized or partitioned somehow (with hardware help) •  OS is a sleeping beauty –  Gets woken up by events –  Enough for time sharing? 3 

4 . Why is the structure of an OS important? •  Protection –  User from user and system from user •  Performance –  Does the structure facilitate good performance? •  Flexibility/Extensibility –  Can we adapt the OS to the application •  Scalability –  Performance goes up with more resources •  Agility –  Adapt to application needs and resources •  Responsiveness –  How quickly it reacts to external events 4 •  Can it meet these requirements? 

5 .Monolithic Kernel Applications OS Services and Device drivers Hardware, managed by OS 5 

6 .DOS Like Structure Applications OS Services and Device drivers What is the difference? Hardware, managed by OS 6 

7 . Extensibility/customization •  Applications are very different; consider video game vs. a number crunching application •  Lets consider a concrete application –  Page fault occurs –  OS action? •  Find a free frame (page replacement policy) •  Update page table •  Resume process •  Providing extensibility was a big area of research 7 

8 . Motivating Extensibility •  Why not one size fits all? •  Both papers make similar arguments –  Traditional centralized resource management cannot be specialized, extended or replaced •  Several papers at the time showed substantial advantages from specializing resource allocation –  Privileged software must be used by all applications –  Fixed high level abstractions too costly for good efficiency •  Also hides information 8 

9 . Micro-kernel Applications Memory File manager CPU System scheduler Micro-kernel IPC, Address Spaces, … Hardware, managed by OS 9 

10 . Discussion of microkernels •  Performance loss! –  A lot of boarder crossings –  Separate address spaces – expensive •  Explicit and implicit costs (memory hierarchy) –  Letscompare a system call for monolithic vs. micro-kernel •  What are the advantages? 10 

11 . Why are microkernels slow? •  Lets consider an example of a file system call –  Application uses system call to microkernel –  Microkernel sends message to file server –  File server does work, then uses ipc to send results back to application •  This requires a border crossing to micro-kernel – Finally switch back to app •  Consider direct cost and loss of locality •  Buffer copies 11 

12 . How expensive are border crossings? •  Procedure call: save some general purpose registers and jump •  Mode switch: –  Trap or call gate overhead •  Nowadays syscall/sysreturn –  Switch to kernel stack –  Switch some segment registers •  Context switch? –  Change address space –  This could be expensive 12 

13 . Summary •  DOS-like structure: –  good performance and extensibility –  Bad protection •  Monolithic kernels: –  Good performance and protection –  Bad extensibility •  Microkernels –  Good protection and extensibility –  Bad performance! 13 

14 . More simply UNIX safe fast Mach Windows/DOS extensible 14 

15 . What should an extensible OS do? •  It should be thin, like a micro-kernel –  Only mechanisms (or even less?) –  no policies; they are defined by extensions •  Fast access to resources, like DOS –  Eliminate boarder crossings •  Flexibility without sacrificing protection or performance •  Basically, fast, protected and flexible 15 

16 . What had been done before? •  Hydra (Wulf ’81) –  Kernel mechanisms for resource allocation –  Capability based resource access •  This was expensive as implemented –  Resource management as coarse grained objects to reduce boarder crossings •  Microkernel (e.g., Mach in the 90s) –  Focus on extensibility and portability –  Portability hurt performance –  Gave a bad rep to microkernels 16 

17 . Previous Work (continued) •  Write extensions in “little languages” –  Allows extensions written in these languages to be added into the kernel –  Extension code is interpreted by kernel at run time •  Limited scope of language limits usefulness of approach 

18 .Spin Approach to extensibility •  Co-location of kernel and extension –  Avoid boarder crossings –  But what about protection? •  Language/compiler forced protection –  Strongly typed language •  Protection by compiler and run-time •  Cannot cheat using pointers –  Logical protection domains •  No longer rely on hardware address spaces to enforce protection – no boarder crossings •  Dynamic call binding for extensibility 18 

19 .SPIN MECHANISMS/TOOLBOX 19 

20 . Logical protection domains •  Modula-3 safety and encapsulation mechanisms –  Type safety, automatic storage management –  Objects, threads, exceptions and generic interfaces •  Fine-grained protection of objects using capabilities. An object can be: –  Hardware resources (e.g., page frames) –  Interfaces (e.g., page allocation module) –  Collection of interfaces (e.g., full VM) •  Capabilities are language supported pointers 20 

21 . Logical protection domains -- mechanisms •  Create: –  Initialize with object file contents and export names •  Resolve: –  Names are resolved between a source and a target domain •  Once resolved, access is at memory speeds •  Combine –  To create an aggregate domain •  This is the key to spin – protection, extensibility and performance 21 

22 . Protection Model (I) •  All kernel resources are referenced by capabilities [tickets] •  SPIN implements capabilities directly through the use of pointers •  Compiler prevents pointers to be forged or dereferenced in a way inconsistent with its type at compile time: –  No run time overhead for using a pointer 

23 . Protection Model (II) •  A pointer can be passed to a user- level application through an externalized reference: –  Indexinto a per-application table of safe references to kernel data structures •  Protection domains define the set of names accessible to a given execution context 

24 . Spin File CPU scheduler System File Memory System manager Network Memory CPU manager scheduler spin IPC, Address Spaces, … Hardware, managed by OS 24 

25 . Spin Mechanisms for Events •  Spin extension model is based on events and handlers –  Which provide for communication between the base and the extensions •  Events are routed by the Spin Dispatcher to handlers –  Handlers are typically extension code called as a procedure by the dispatcher –  One-to-one, one-to-many or many-to-one •  All handlers registered to an event are invoked –  Guards may be used to control which handler is used 25 

26 .Event example 26 

27 .PUTTING IT ALL TOGETHER 27 

28 .Default Core services in SPIN •  Memory management (of memory allocated to the extension) –  Physical address •  Allocate, deallocate, reclaim –  Virtual address •  Allocate, deallocate –  Translation •  Create/destory AS, add/remove mapping –  Event handlers •  Page fault, access fault, bad address 28 

29 . CPU Scheduling •  Spin abstraction: strand –  Semantics defined by extension •  Event handlers –  Block, unblock, checkpoint, resume •  Spin global scheduler –  Interacts with extension threads package 29