OS Organization Continued Andy Wang COP 5611 Advanced Operating Systems Outline Overall organization of microkernel systems Spring Organizing the Total System In microkernel organizations much of the OS is outside the microkernel But that doesn t answer the question of how the system as a whole gets organized How do you fit together the components to build an integrated system While maintaining all the advantages of the microkernel A Sample Microkernel OS Spring Developed by Sun Intended to examine how to improve OSes by building from the ground up Approach was to address the greatest problem in building operating systems In some sense a response to problems with UNIX UNIX Problems Spring Addresses Cost of maintaining evolving system Inflexible security model Hard to build distributed services Hard to handle real time issues Multiplicity of naming schemes Basic Spring Approach Make it possible for others to extend the OS itself through strong interfaces Which are open flexible and extensible Spring designers clearly learned from success of extensible UNIX features like VFS OS as set of cooperating services Object Oriented Organizations Object oriented organization is increasingly popular Well suited to OS development in some ways OSes manage important data structures OSes are modularizable Strong interfaces are good in OSes Object Orientation and Extensibility One of the main advantages of object oriented programming is extensibility Operating systems increasingly need extensibility So again object oriented techniques are a good match for operating system design How object oriented should an OS be Many OSes have been built with objectoriented techniques E g Mach and Windows NT But most of them leave object orientation at the microkernel boundary No attempt to force object orientation on out ofkernel modules Spring is a Microkernel System Spring microkernel consists of nucleus and basic virtual memory support Nucleus supports operating system objects With security And high speed object invocation Spring Object Managers Spring is implemented as microkernel plus a suite of object managers Running in non kernel mode In private address spaces Adding new functionality to Spring amounts to adding a new object manager Object managers are objects themselves Spring s Interface Definition Language Spring wants to avoid being tied to a single language But it also requires strong interfaces to allow for extensibility So Spring interfaces are written in IDL Interfaces are defined in IDL but IDL says nothing about implementation IDL Compilers Convert IDL definitions of interfaces into particular languages To generate language specific form of the interface for use of objects written in that language Also generates client and server stub code for use by objects deploying the interface Objects in Spring Object users invoke operations defined in its interface The operation could be preformed in The same address space A different address space on the same machine A different address space on a different machine Server Based Objects Server based Spring objects live in their own address spaces IDL generates stubs for their benefit Subcontracts and doors used to communicate between clients and servers Essentially they are passed to another address space by a pointer Serverless Objects Objects kept in the caller s address space Typically used for lightweight objects most of local interest Can be passed to another address space by copying Parts of a Spring Object From the client s point of view an object consists of A method table A subcontract operation vector Client local private state representation Spring Object Diagram Method Table Subcontract Table Representation Methods and Spring Objects Spring object methods are either handled in the object s local address space Or in a remote address space Through the method table Through the subcontract table Subcontracts essentially allow other objects to handle your methods for you Spring Subcontracts Semantics of invoking an object in a different address space can vary Can the object be replicated Can it support an atomic transaction Can it migrate Is it persistent Spring subcontracts allow this flexibility In the context of RPC Subcontracts and Extensibility Subcontracts are essentially an extensibility mechanism They allow service providers to extend the service Without requiring clients to do things differently Essentially subcontracts sit between interfaces and implementations Simple Subcontracts One example is a subcontract for invoking a method on an object at a remote server Subcontract implements the machinery for communicating with the remote server Methods simply marshal arguments and call the subcontract in this case Simple Subcontract Diagram Client Application Server Application Client Stubs Server Stubs Subcontract Subcontract So what can I do with subcontracts One example a simple replication service Users access through client object Server objects maintain replication Client object has representation showing where each server maintaining a replica is All local methods are stub calls to subcontracts Replication Subcontract Diagram Client object Server object 1 Server object 2 Client replication subcontract Server replication subcontract Server replication subcontract Replication Subcontract Diagram Client object Server object 1 Server object 2 Client replication subcontract Server replication subcontract Server replication subcontract Other Types of Subcontracts The simplex subcontract the simplest subcontract that uses one door to communicate with a server RPC The cluster subcontract uses a single door to access a set of objects The caching subcontract supports access to either remote object or local caching object Spring Nucleus Abstractions Domains Threads Doors All used to support Spring s basic object model Spring Domains Provide address space and container to hold application resources Similar to UNIX processes Or Mach tasks Spring Threads Unit of execution in Spring Similar to threads in other systems Spring domains are typically multithreaded Spring Doors Abstraction supporting interdomain objectoriented method calls A door describes an entry point to a domain Also like a capability Possession of a door implies right to invoke an object s method Protecting Doors Since doors are capabilities kernel must protect them to provide security Domains don t hold doors themselves They hold door identifiers Door identifiers point to doors
View Full Document
Unlocking...