DOC PREVIEW
Operating System Structure

This preview shows page 1-2-16-17-18-33-34 out of 34 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 34 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 34 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 34 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 34 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 34 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 34 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 34 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 34 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Operating System StructureJoey [email protected] 23, 2004Carnegie Mellon University: 15-410 Spring 2004Overview• Motivations• Kernel Structures– Monolithic Kernels– Open Systems– Microkernels– Kernel Extensions– Exokernels• Final Thoughts2Motivations• Operating systems have a hard job.• Operating systems are:– Abstraction layers– Resource allocators– Protection boundaries– Schedulers– Complicated3Motivations• 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 devices4Motivations• Protection Boundaries– Operating systems protect processes from each other and itself fromprocess.– Note: Everyone trusts the kernel.• Schedulers– Operating systems schedule access to resources.– e.g., process scheduling, disk scheduling, etc.• Complicated– See Project 3 :)5Monolithic KernelsKernelSecurityDiskCPUlibc libpthread libc libpthreadMozillaApache EmacslibcCPU SchedulingVirtual MemoryNetworkingFile SystemDevice DriversInterprocess CommunicationI/OMemory Network6Monolithic 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 thekernel.• Examples: UNIX, Mac OS X, Windows NT/XP, Linux, BSD, i.e., common7Monolithic 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 modules8Open SystemsKernel andApplicationsApacheEmacsNetworkinglibclibpthreadMozillaVirtual Memory File SystemDevice DriversInterprocess CommunicationDiskNetworkMemoryCPU I/O9Open 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 common10Open 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 results11MicrokernelsDisk I/OMozillalibclibcMicrokernelCPU Memory NetworklibclibpthreadApachelibpthreadVirtual MemoryProcessesNetworkingFile SystemEmacsDevice DriversCPU SchedulingInterprocess Communication Security12Microkernels• Replace the monolithic kernel with a small set of abstractions needed tosupport the hardware.• Move the rest of the OS into server processes• The microkernel provides security, IPC, and a small level of hardwareinteraction.• Examples: Mach, Chorus, QNX, GNU/Hurd, L4• Mixed results: QNX successful in the embedded space, microkernels aremostly nonexistent elsewhere13Microkernels• 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.14Microkernels• Disadvantages:– Performance∗ Never really verified∗ But it was a common complaint∗ Real answer: No one knows– Expensive to re-implement everything using a new model15Mach• 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 syscalls16Mach• What actually happened:– Proof of concept∗ Completed in 1989∗ Unix: smp, kernel threads, 5 architectures∗ Commercial deployment: Encore Multimax, Convex Exemplar (SPP-UX), 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)17GNU Hurd• Hurd stands for ’Hird of Unix-Replacing Daemons’ and Hird stands for ’Hurdof 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™18Kernel ExtensionsUser Kernel ExtensionsDefault ServicesCore ServicesFast SocketslibcApachelibpthreadMozillalibc libpthread libcEmacsCustom FSFile System Networking Device DriversCPU SchedulerVM SecurityInterprocess CommunicationCPU Memory Network DiskKernelI/OFS and Sockets19Kernel 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”20Kernel 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? Gauranteed21Kernel 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 extensibility22Pause• 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.23ExokernelsMozillaFast SocketsVMEmacslibPosixExokernelSecurityTLBDiskCPU Memory NetworkCPU SchedulerI/OFSFast


Operating System Structure

Download Operating System Structure
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

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

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

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

or

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

Already a member?