1CSE 120CSE 120Principles of Operating Principles of Operating SystemsSystemsFall 2002Fall 2002Lecture 15: StructureLecture 15: StructureGeoffrey M. VoelkerGeoffrey M. VoelkerNovember 26, 2002 CSE 120 – Lecture 15 – Structure 2© 2002 Geoffrey M. VoelkerStructureStructurez We have talked about the major modules that comprise an operating systemz Today we will discuss different ways to compose them2November 26, 2002 CSE 120 – Lecture 15 – Structure 3© 2002 Geoffrey M. VoelkerThe Challenge of StructureThe Challenge of Structurez It is clear what modules an OS should providez Not so clear how to hook them together (well)…File SystemProcess ManagementMemory ManagementI/O SubsystemAccountingCommand InterpreterSecondary StorageProtectionNovember 26, 2002 CSE 120 – Lecture 15 – Structure 4© 2002 Geoffrey M. VoelkerOS StructureOS Structurez An OS consists of all of the above modules, others we haven’t discussed, system programs (privileged and non-privileged), etc.z The challengeX How do we organize it all?X What are the modules, where do they exist?X How do they cooperate?z How do we build a complex software system that is:X Large and complexX ConcurrentX Long-lived and evolvingX Performance-critical3November 26, 2002 CSE 120 – Lecture 15 – Structure 5© 2002 Geoffrey M. VoelkerMonolithic KernelsMonolithic Kernelsz Traditionally, OSes such as Unix are built as a monolithic kernel (BSD, SYSV, Solaris, Linux, etc.)User ProgramsHardwareEverything OS KernelNovember 26, 2002 CSE 120 – Lecture 15 – Structure 6© 2002 Geoffrey M. VoelkerMonolithic ProblemsMonolithic Problemsz Monolithic kernels have one great featureX The overhead of inter-module interaction is lowz Monolithic kernels have a number of problemsX Hard to understandX Hard to modifyX Hard to maintainX Unreliable (a bug in one module can take down entire system)» Memory corruption bugs in Nachosz From the beginning, OS designers have sought ways to organize the OS to simplify design and construction4November 26, 2002 CSE 120 – Lecture 15 – Structure 7© 2002 Geoffrey M. VoelkerLayeringLayeringz An early approach is layeringX Each system service is a layerX Each layer defines and implements an abstraction for the layer above itX Layers in effect “virtualize” the layer belowz Approach first used by Dijkstra’s THE system (1968)X Analogous to protocol layers in networking stacksNovember 26, 2002 CSE 120 – Lecture 15 – Structure 8© 2002 Geoffrey M. VoelkerTHE SystemTHE Systemz Levels see a virtual machine provided by lower levelX Level 1 (CPU scheduling)X Level 2 (memory management) sees virtual processorsX Level 3 (console) sees VM (segments)X Level 4 (device buffers) sees a “virtual console”X Level 5 (user programs) sees “virtual” I/O driversz System composed of a set of sequential processesX Processes communicate via synchronization in memoryz Key: Each layer could be tested and verified independently5November 26, 2002 CSE 120 – Lecture 15 – Structure 9© 2002 Geoffrey M. VoelkerLayering ProblemsLayering Problemsz Layered systems are hierarchical, but real systems have much more complex interactionsX File system requires VM services (data structures, buffers)X VM requires file system services (backing store)X What do you do?z Layering not flexible enoughz Can have poor performanceX Depends on how layers interactz Systems often modeled as layered structures, but not built as suchNovember 26, 2002 CSE 120 – Lecture 15 – Structure 10© 2002 Geoffrey M. VoelkerMicrokernel StructureMicrokernel Structurez Microkernel structures were hot in late 80s, early 90sz Minimize kernel services, implement remaining OS modules as user-level processesX Better reliability (file system dies, restart it…)X Easier to extend and customize (start a new process)X Support multiple coexisting OS implementationsz But, mediocre performanceX Overhead of inter-module interaction is high (c.f. monolithic)z First microkernel system was Hydra (CMU, 1970)z Others: Mach (CMU), Chorus, NT6November 26, 2002 CSE 120 – Lecture 15 – Structure 11© 2002 Geoffrey M. VoelkerMicrokernel StructureMicrokernel StructureUser ProgramsHardwareCommunicationMicrokernelOS ModulesLow-level VMCPU schedulingProtectionFile SystemExternal PagerNetworkProcessesH/L SchedulingUser ModeKernel ModeNovember 26, 2002 CSE 120 – Lecture 15 – Structure 12© 2002 Geoffrey M. VoelkerWindows NT 3.1 (1993)Windows NT 3.1 (1993)User ProgramsHardwareObject ManagerNT ExecutiveProtected SubsystemsVirtual MemoryProcessesI/OOS/2Win32PosixSecurityUser ModeKernel ModeHardware Abstraction Layer HALSecurityLocal Proc CallKernel Services7November 26, 2002 CSE 120 – Lecture 15 – Structure 13© 2002 Geoffrey M. VoelkerSingle Address Space OSSingle Address Space OSz A single address space OS has the operating system and all applications in the same address spacez Three examplesX MS-DOS and early MacOS (80s, early 90s)X Pilot (Xerox PARC in late 70s)X Opal (Univ. of Washington in early 90s)z BenefitsX Low overhead interaction between user programs and kernelz The key question is protectionX How do we protect kernel from apps, apps from each other?November 26, 2002 CSE 120 – Lecture 15 – Structure 14© 2002 Geoffrey M. VoelkerProtection in Protection in SASsSASsz No protection: MS-DOS and MacOSX Apps can take down the machinez Language support: PilotX Pilot relied upon language support for memory protection» Mesa – think precursor to JavaX A single-user operating system for an early PC prototypeX Assumption was that all code (OS and applications) was owned by the same user» Subverting the OS only subverts yourselfX Simplified policies and app/OS interaction8November 26, 2002 CSE 120 – Lecture 15 – Structure 15© 2002 Geoffrey M. VoelkerProtection in Protection in SASsSASs(2)(2)z Hardware support: OpalX Separate naming from protection in address spaces» Standard ASs provide both, but do not have toX Single address space partitioned into protection domainsX Processes require capabilities to execute within a domain» Think large, unforgeable key checked on every memory opz Why do this?X Easy to share and persist complex data structures» Every process can use the same pointers» Even save them on disk and restore them without modificationX Want “names” (addresses) to be persistent» Across space (machines in a cluster) and time (never reused)» Requires large address spaces (64-bit or larger)November 26, 2002 CSE 120 – Lecture 15 –
View Full Document
Unlocking...