Advanced Operating Systems

1. Advanced Operating Systems Lecture 3: OS design University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani Distributed Operating Systems

2. How to design an OS • Some general guides and experiences. • References • “The Computer for the 21st Century”, Mark Weiser • “Exokernel: An Operating System Architecture for Application Level Resource Management”, Dawson R., Engler M, Frans Kaashoek, et al. • “On Micro-Kernel Constructions“, Distributed Operating Systems

3. Outline • New applications/requirements • Organizing operating systems • Some microkernel examples • Object-oriented organizations • Spring • Organization for multiprocessors Distributed Operating Systems

4. New vision • Two important problems: location and scale. • Ubiquitous computing: tiny kernels of functionality • Virtual Reality • Mobility • Intelligent devices • distributed computing" make networks appear like disks, memory, or other nonnetworked devices. Distributed Operating Systems

5. Ubiquitous computing • Transparent computing is the ultimate goal • Computers should disappear into the background • Computation becomes part of the environment • Computing everywhere • Desktop, Laptop, Palmtop • Cars, Cell phones • Shoes, Clothing, Walls (paper / paint) • Connectivity everywhere • Broadband • Wireless • Mobile everywhere • Users move around • Disposable devices Distributed Operating Systems

6. Ubiquitous Computing • Structure • Resource and service discovery critical • User location an issue • Interface discovery • Disconnected operation • Ad-hoc organization • Security • Small devices with limited power • Intermittent connectivity • Agents • Sensor Networks Distributed Operating Systems

7. Grid Computing • Federated system • No single controlling authority • Scheduling • Processors, bandwidth and other resources • Policy is an important issue • Reliability, security, of who can use, and what one is willing to use. • Systems • Globus toolkit • Condor • Related but not grid – CORBA, DCOM, DCE • Applications • Distributed supercomputing Distributed Operating Systems

8. Peer-to-Peer Computing • Locating Cooperative elements • Scalability • OS support • Security • Policies

9. P2P File Sharing Issues • Naming • Data discovery • Availability • Security • Encryption • Fault tolerance • Conflict resolution • Replication Distributed Operating Systems

10. Other Peer to Peer Technologies • Ad-hoc networking • Untrusted nodes used to relay messages • Multiple routes (distributed and replicated) • Extends range, reduces power, increases aggregate bandwidth. • Increases latency, management more difficult. • Sensor networks • An application of ad-hoc networking • Add processing/reduction in the network Distributed Operating Systems

11. What is the big deal? • Performance • Border crossings are expensive • Change in locality • Copying between user and kernel buffers • Application requirements differ in terms of resource management Distributed Operating Systems

12. Operating System Organization • What is the best way to design an operating system? • Put another way, what are the important software characteristics of an OS? • What should be in OS kernel or application or partitioning. • Is there a minimal set for kernel? Distributed Operating Systems

13. Important OS Software Characteristics • Correctness and simplicity • Power and completeness • Performance • Extensibility and portability • Flexibility • Scalability • Suitability for distributed and parallel systems • Compatibility with existing systems • Security and fault tolerance Distributed Operating Systems

14. Common OS Organizations • Monolithic • Virtual machine • Layered designs • Kernel designs • Microkernels • Object-Oriented • Note that individual OS components can be organized these ways • Trade off between generality and specialization

15. What are we shooting for? • OS should be thin (like a microkernel) providing only mechanisms not embodying policies (i.e. management) • Fine grain access to system resources while avoiding border crossings as much as possible (like DOS) • Allow flexible extensions for management of resources (like a microkernel) without sacrificing safety (like a monolithic kernel) Distributed Operating Systems

16. Monolithic OS Design • Build OS as single combined module • Hopefully using data abstraction, compartmentalized function, etc. • OS lives in its own, single address space • Examples • DOS • early Unix systems • most VFS file systems

17. Pros/Cons of Monolithic OS Organization • Highly adaptable (at first . . .) • Little planning required • Potentially good performance • Hard to extend and change • Eventually becomes extremely complex • Eventually performance becomes poor • Highly prone to bugs

18. Virtual Machine Organizations • A base operating system provides services in a very generic way • One or more other operating systems live on top of the base system • Using the services it provides • To offer different views of system to users • Examples - IBM’s VM/370, the Java interpreter

19. Pros/Cons of Virtual Machine Organizations • Allows multiple OS personalities on a single machine • Good OS development environment • Can provide good portability of applications • Significant performance problems • Especially if more than 2 layers • Lacking in flexibility

20. Old idea • VM 370 • Virtualization for binary support for legacy apps • Why resurgence today? • Companies want a share of everybody’s pie • IBM zSeries “mainframes” support virtualization for server consolidation • Enables billing and performance isolation while hosting several customers • Microsoft has announced virtualization plans to allow easy upgrades and hosting Linux! • You can see the dots connecting up • From extensibility (a la SPIN) to virtualization Distributed Operating Systems

21. Possible virtualization approaches • Standard OS (such as Linux, Windows) • Meta services (such as grid) for users to install files and run processes • Administration, accountability, and performance isolation become hard • Retrofit performance isolation into OSs • Linux/RK, QLinux, SILK • Accounting resource usage correctly can be an issue unless done at the lowest level (e.g. Exokernel) • Xen approach • Multiplex physical resource at OS granularity Distributed Operating Systems

22. Full virtualization • Virtual hardware identical to real one • Relies on hosted OS trapping to the VMM for privileged instructions • Pros: run unmodified OS binary on top • Cons: • supervisor instructions can fail silently in some hardware platforms (e.g. x86) • Solution in VMware: Dynamically rewrite portions of the hosted OS to insert traps • need for hosted OS to see real resources: real time, page coloring tricks for optimizing performance, etc… Distributed Operating Systems

23. Xen principles • Support for unmodified application binaries • Support for multi-application OS • Complex server configuration within a single OS instance • Paravirtualization for strong resource isolation on uncooperative hardware (x86) • Paravirtualization to enable optimizing guest OS performance and correctness Distributed Operating Systems

24. Xen: VM management • What would make VM virtualization easy • Software TLB • Tagged TLB =>no TLB flush on context switch X86 does not have either • Xen approach • Guest OS responsible for allocating and managing hardware PT • Xen top 64MB of every address space. Why? Distributed Operating Systems

25. Layered OS Design • Design tiny innermost layer of software • Next layer out provides more functionality • Using services provided by inner layer • Continue adding layers until all functionality required has been provided • Examples • Multics • Fluke • layered file systems and comm. protocols

26. Pros/Cons of Layered Organization • More structured and extensible • Easy model and development • Performance: Layer crossing can be expensive • In some cases, unnecessary layers, duplicated functionality.

27. Kernel OS Designs • Similar to layers, but only two OS layers • Kernel OS services • Non-kernel OS services • Move certain functionality outside kernel • file systems, libraries • Unlike virtual machines, kernel doesn’t stand alone • Examples - Most modern Unix systems

28. Pros/Cons of Kernel OS Organization • Many advantages of layering, without disadvantage of too many layers • Easier to demonstrate correctness • Not as general as layering • Offers no organizing principle for other parts of OS, user services • Kernels tend to grow to monoliths

29. Object-Oriented OS Design • Design internals of OS as set of privileged objects, using OO methods • Sometimes extended into application space • Tends to lead to client/server style of computing • Examples • Mach (internally) • Spring (totally)

30. 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 Distributed Operating Systems

31. 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 Distributed Operating Systems

32. How object-oriented should an OS be? • Many OSes have been built with object-oriented 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-of-kernel modules Distributed Operating Systems

33. Pros/Cons of Object Oriented OS Organization • Offers organizational model for entire system • Easily divides system into pieces • Good hooks for security • Can be a limiting model • Must watch for performance problems Not widely used yet

34. Microkernel OS Design • Like kernels, only less number of abstractions exported (threads, address space, communication channel) • Try to include only small set of required services in the microkernel • Moves even more out of innermost OS part • Like parts of VM, IPC, paging, etc. • System services (e.g. VM manager) implemented as servers on top • High comm overhead between services implemented at user level and microkernel limits extensibility in practice • Examples - Mach, Amoeba, Plan 9, Windows NT, Chorus, Spring, etc.

35. Pros/Cons of Microkernel Organization • Those of kernels, plus: • Minimizes code for most important OS services • Offers model for entire system • Microkernels tend to grow into kernels • Requires very careful initial design choices • Serious danger of bad performance

36. 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 Distributed Operating Systems

37. Some Important Microkernel Designs Micro-ness is in the eye of the beholder • Mach • Spring • Amoeba • Plan 9 • Windows NT

38. Mach • Mach didn’t start life as a microkernel • Became one in Mach 3.0 • Object-oriented internally • Doesn’t force OO at higher levels • Microkernel focus is on communications facilities • Much concern with parallel/distributed systems

39. Mach Model User processes User space Software emulation layer 4.3BSD emul. SysV emul. HP/UX emul. other emul. Kernel space Microkernel

40. What’s In the Mach Microkernel? • Tasks & Threads • Ports and Port Sets • Messages • Memory Objects • Device Support • Multiprocessor/Distributed Support

41. Mach Tasks • An execution environment providing basic unit of resource allocation • Contains • Virtual address space • Port set • One or more threads

42. Mach Task Model Address space Process User space Thread Process port Bootstrap port Exception port Registered ports Kernel

43. Mach Threads • Basic unit of Mach execution • Runs in context of one task • All threads in one task share its resources • Unix process similar to Mach task with single thread

44. Task and Thread Scheduling • Very flexible • Controllable by kernel or user-level programs • Threads of single task can execute in parallel • On single processor • Multiple processors • User-level scheduling can extend to multiprocessor scheduling

45. Mach Ports • Basic Mach object reference mechanism • Kernel-protected communication channel • Tasks communicate by sending messages to ports • Threads in receiving tasks pull messages off a queue • Ports are location independent • Port queues protected by kernel; bounded

46. Port Rights • mechanism by which tasks control who may talk to their ports • Kernel prevents messages being set to a port unless the sender has its port rights • Port rights also control which single task receives on a port Distributed Operating Systems

47. Port Sets • A group of ports sharing a common message queue • A thread can receive messages from a port set • Thus servicing multiple ports • Messages are tagged with the actual port • A port can be a member of at most one port set Distributed Operating Systems

48. Mach Messages • Typed collection of data objects • Unlimited size • Sent to particular port • May contain actual data or pointer to data • Port rights may be passed in a message • Kernel inspects messages for particular data types (like port rights)

49. Mach Memory Objects • A source of memory accessible by tasks • May be managed by user-mode external memory manager • a file managed by a file server • Accessed by messages through a port • Kernel manages physical memory as cache of contents of memory objects

50. Mach Device Support • Devices represented by ports • Messages control the device and its data transfer • Actual device driver outside the kernel in an external object