可扩展操作系统

本章主要讲述可拓展操作系统的基本概念及其应用。讨论了OS的组织结构和关于它的应用。从基本概念开始,慢慢深入到学习它们的操作及应用。
展开查看详情

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