View Full Document


Unformatted text preview:

Operating System Structure Joey Echeverria jge andrew cmu edu April 23 2004 Carnegie Mellon University 15 410 Spring 2004 Overview Motivations Kernel Structures Monolithic Kernels Open Systems Microkernels Kernel Extensions Exokernels Final Thoughts 2 Motivations Operating systems have a hard job Operating systems are Abstraction layers Resource allocators Protection boundaries Schedulers Complicated 3 Motivations Abstraction Layer Operating systems present a simplified view of hardware Applications see a well defined interface system calls Resource Allocator Operating systems allocate hardware resources to processes memory network disk space CPU time I O devices 4 Motivations Protection Boundaries Operating systems protect processes from each other and itself from process Note Everyone trusts the kernel Schedulers Operating systems schedule access to resources e g process scheduling disk scheduling etc Complicated See Project 3 5 Monolithic Kernels Apache Mozilla libc libpthread libc libpthread Kernel CPU Scheduling Emacs libc Interprocess Communication Virtual Memory File System Networking Device Drivers Security CPU Memory Network Disk I O 6 Monolithic Kernels You ve seen this before The kernel is all in one place with no protection between components Applications use a well defined system call interface to interact with the kernel Examples UNIX Mac OS X Windows NT XP Linux BSD i e common 7 Monolithic Kernels Advantages Well understood Good performance High level of protection between applications Disadvantages No protection between kernel components Not extensible Overall structure is complicated Everything is intermixed There aren t clear boundaries between modules 8 Open Systems Kernel and Applications Apache Mozilla libpthread libc Emacs Interprocess Communication Virtual Memory File System Networking CPU Memory Network Disk Device Drivers I O 9 Open Systems Applications libraries and kernel all sit in the same address space Does anyone actually do this craziness MS DOS Mac OS 9 and prior Windows ME and prior PalmOS some embedded systems Used to be very common 10 Open Systems Advantages Very good performance Very extensible Undocumented Windows Schulman et al 1992 In the case of Mac OS and PalmOS there s an extensions industry Can work well in practice Disadvantages No protection between kernel and or applications Not particularly stable Composing extensions can result in unpredictable results 11 Microkernels Mozilla Networking libc libpthread Apache Emacs Processes libc libpthread libc File System Virtual Memory Microkernel Interprocess Communication Security Device Drivers CPU Scheduling CPU Memory Network Disk I O 12 Microkernels Replace the monolithic kernel with a small set of abstractions needed to support the hardware Move the rest of the OS into server processes The microkernel provides security IPC and a small level of hardware interaction Examples Mach Chorus QNX GNU Hurd L4 Mixed results QNX successful in the embedded space microkernels are mostly nonexistent elsewhere 13 Microkernels Advantages Extensible just add a new server to extend the kernel Operating system agnostic Support of operating system personalities Have a server for each system Mac Windows UNIX All applications can run on the same kernel IBM Workplace OS one kernel for OS 2 OS 400 and AIX based on Mach 3 0 failure High security the operating system is protected even from itself Naturally extended to distributed systems 14 Microkernels Disadvantages Performance Never really verified But it was a common complaint Real answer No one knows Expensive to re implement everything using a new model 15 Mach Started as a project at CMU based on RIG project from Rochester Plan Proof of concept Take BSD 4 1 fix parts like VM user visible kernel threads ipc Microkernel and a single server Take the kernel and saw in half Microkernel and multiple servers FS paging network etc Servers glued together by OS personality modules which catch syscalls 16 Mach What actually happened Proof of concept Completed in 1989 Unix smp kernel threads 5 architectures Commercial deployment Encore Multimax Convex Exemplar SPPUX OSF 1 Avie Tevanian took this to NeXT NeXTStep OS X Microkernel and a single server Completed deployed to 10 s of machines everybody graduated Microkernel and multiple servers FS paging network etc Never really completed everybody graduated 17 GNU Hurd Hurd stands for Hird of Unix Replacing Daemons and Hird stands for Hurd of Interfaces Representing Depth GNU Hurd is the FSF s kernel Work began in 1990 on the kernel The kernel is to be completed Real Soon Now 18 Kernel Extensions Apache Mozilla libc libpthread libc libpthread Kernel Custom FS File System CPU Scheduler CPU Fast Sockets Networking Emacs libc FS and Sockets Device Drivers User Kernel Extensions Default Services VM Interprocess Communication Security Core Services Memory Network Disk I O 19 Kernel Extensions Two related ideas old way and new way Old way System administrator adds a new whatever to an existing kernel This can be hot or may require a reboot no compiling VMS Windows NT Linux BSD Mac OS X Safe of course 20 Kernel Extensions New way Allow users to download enhancements into the kernel This can be done with type safety Spin Modula 3 or proof carrying code PCC Spin University of Washington Proof carrying code CMU Safe Gauranteed 21 Kernel Extensions Advantages Extensible just add a new extension Safe New way Good performance because everything is in the kernel Disadvantages Rely on compilers PCC proof checker head of project etc for safety Constrain implementation language on systems like Spin The old way doesn t give safety but does give extensibility 22 Pause So far we ve really just moving things around There is still a VM system file system IPC etc Why should I trust the kernel to give me a filesystem that is good for me Let s try something different 23 Exokernels Apache Mozilla Emacs Fast Sockets FS VM Fast Sockets VM libPosix Exokernel TLB Security CPU Scheduler CPU Memory Network Disk I O 24 Exokernels Basic idea Take the operating system out of the kernel and put it into libraries Why Applications know better how they want hardware resources managed than kernel writers do Is this safe Sure the Exokernel s job is to provide safe multiplexed access to the hardware This separates the security and protection from the management of resources 25 Exokernels VM Example There is no fork There is no exec There is no automatic stack

Access the best Study Guides, Lecture Notes and Practice Exams

Loading Unlocking...

Join to view Operating System Structure and access 3M+ class-specific study document.

We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Operating System Structure and access 3M+ class-specific study document.


By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?