CSE 421/521 - Operating Systems Roadmap Fall 2013 • OS Design and Implementation – Different Design Approaches Lecture - II • Major OS Components OS Structures ! Processes ! Memory management ! CPU Scheduling ! I/O Management Tevfik Ko ş ar University at Buffalo August 29 th , 2013 1 2 Operating System Design and Implementation • Start by defining goals and specifications • Affected by choice of hardware, type of system – Batch, time shared, single user, multi user, distributed OS Design Approaches • User goals and System goals – User goals – operating system should be convenient to use, easy to learn, reliable, safe, and fast – System goals – operating system should be easy to design, implement, and maintain, as well as flexible, reliable, error- free, and efficient • No unique solution for defining the requirements of an OS " Large variety of solutions " Large variety of OS 3 4 System Calls Operating System Design and Implementation (Cont.) • System calls are the only entry points into the kernel and system • Important principle: to separate policies and mechanisms User programs Policy: What will be done? Mechanism: How to do something? Library functions & programs user space • Eg. to ensure CPU protection . . . fputs, getchar, ls, pwd, more . . . . . . fork, open, read System calls rm, chmod, kill . . . – Use Timer construct (mechanism) the “middleman’s Operating system counter” – How long to set the timer (policy) kernel space • The separation of policy from mechanism allows maximum flexibility if policy decisions are to be • Programming interface to the services provided by the OS changed later • All programs needing resources must use system calls • Most UNIX commands are actually library functions and utility programs (e.g., shell interpreter) built on top of the system calls 5
Example Dual-Mode Operation • C program invoking printf() library call, which calls write() system call • Dual-mode operation allows OS to protect itself and other system components – User mode and kernel mode – Mode bit provided by hardware • Provides ability to distinguish when system is running user code or kernel code • Protects OS from errant users, and errant users from each other • Some instructions designated as privileged , only executable in kernel mode • System call changes mode to kernel, return from call resets it to user 7 8 Transition from User to Kernel Mode Questions • How to prevent user program getting stuck in an • At the system boot time, what should be the mode of infinite loop / process hogging resources operation? # Timer: Set interrupt after specific period (1ms to 1sec) • When to switch to user mode? – Operating system decrements counter • When to switch to kernel mode? – When counter zero generate an interrupt – Set up before scheduling process to regain control or terminate • Which of these are mechanisms? program that exceeds allotted time • Which of these are policies? 9 10 OS Design Approaches Simple Structure • Simple Structure • No well defined structure • Layered Approach • Start as small, simple, limited systems, and then grow • Microkernels • No well defined layers, not divided into modules • Modules 11 12
Simple Structure Layered Approach $ Example: MS-DOS Silberschatz, A., Galvin, P. B. and Gagne. G. (2003) $ Monolithic operating systems Operating Systems Concepts with Java (6th Edition). initially written to provide % % no one had experience in building truly large software systems the most functionality in % the problems caused by mutual dependence and interaction the least space were grossly underestimated started small and grew % % such lack of structure became unsustainable as O/S grew beyond its original scope % Early UNIX, Linux, Windows systems --> monolithic, partially levels not well separated: % layered programs could access I/O $ Enter hierarchical layers and information abstraction devices directly % each layer is implemented exclusively using operations % excuse: the hardware of provided by lower layers that time was limited (no % it does not need to know how they are implemented dual user/kernel mode) MS-DOS pseudolayer structure % hence, lower layers hide the existence of certain data structures, private operations and hardware from upper layers 13 14 Simple Layered Approach Full Layered Approach The original UNIX $ • The operating system is divided % enormous amount of into a number of layers (levels), Silberschatz, A., Galvin, P. B. and Gagne. G. (2003) functionality crammed Operating Systems Concepts with Java (6th Edition). each built on top of lower layers. into the kernel - everything below – The bottom layer (layer 0), is the system call interface hardware; % “The Big Mess”: a – The highest (layer N) is the user collection of interface. procedures that can • With modularity, layers are call any of the other selected such that each uses procedures whenever functions (operations) and services they need to of only lower-level layers % no encapsulation, total visibility across the • THE system (by Dijkstra), MULTICS, system GLUnix, VAX/VMS UNIX system structure % very minimal layering made of thick, monolithic layers 15 16 Layered Approach Layered Approach Theoretical model of operating system design hierarchy $ Layers can be debugged and replaced independently without bothering the other layers above and below shell % famous example of famous example of % strictly layered strictly layered architecture: the architecture: TCP/IP networking N+ 1 O/S offers services stack N uses services N –1 hardware Stallings, W. (2004) Operating Systems: Internals and Design Principles (5th Edition). 17 18
Layered Approach Layered Approach $ Major difficulty with layering $ Circular dependencies in an O/S organization % . . . appropriately defining the various layers! % example: disk driver routines vs. CPU scheduler routines % layering is only possible if all function dependencies can be & the device driver for the backing store (disk space used by sorted out into a Directed Acyclic Graph (DAG) virtual memory) may need to wait for I/O, thus invoke the CPU-scheduling layer % however there might be conflicts in the form of circular dependencies (“cycles”) & the CPU scheduler may need the backing store driver for swapping in and out parts of the table of active processes $ Other difficulty: efficiency % the more layers, the more indirections from function to function and the bigger the overhead in function calls % backlash against strict layering: return to fewer layers with more functionality Circular dependency on top of a DAG 19 20 Microkernel System Structure Layered OS vs Microkernel $ The microkernel approach % a microkernel is a reduced operating system core that contains only essential O/S functions % the idea is to minimize the kernel by moving up as much functionality as possible from the kernel into user space % many services traditionally included in the O/S are now external subsystems running as user processes device drivers & & file systems & virtual memory manager & windowing system & security services, etc. 21 22 Microkernel System Structure Modular Approach $ Benefits of the microkernel approach $ The modular approach % extensibility — it is easier to extend a microkernel-based O/S as new % many modern operating systems implement kernel modules services are added in user space, not in the kernel (Modern UNIX, Solaris, Linux, Windows, Mac OS X) % portability — it is easier to port to a new CPU, as changes are needed only % this is similar to the object-oriented approach: in the microkernel, not in the other services & each core component is separate % reliability & security — much less code is running in kernel mode; failures in user-space services don’t affect kernel space & each talks to the others over known interfaces & each is loadable as needed within the kernel $ Detriments of the microkernel approach % overall, modules are similar to layers but with more flexibility % again, performance overhead due to communication from user space to (any model could call any other module) kernel space % modules are also similar to the microkernel approach, except % not always realistic: some functions (I/O) must remain in kernel space, they are inside the kernel and don’t need message passing forcing a separation between “policy” and “mechanism” • Examples: QNX, Tru64 UNIX, Mach (CMU), Windows NT 23 24
Modular Approach Hybrid Systems $ Modules are used in Solaris, Linux and Mac OS X • Many real OS use combination of different approaches • Linux: monolithic & modular • Windows: monolithic & microkernel & modular • Mac OS X: microkernel & modular Silberschatz, A., Galvin, P. B. and Gagne. G. (2003) Operating Systems Concepts with Java (6th Edition). The Solaris loadable modules 25 26 Mac OS X Structure - Hybrid Major OS Components • BSD: provides support for command line interface, networking, file system, POSIX API and threads • Mach: memory management, RPC, IPC, message passing 27 28 Major OS Components Processes $ A process is the activity of executing a program ! Processes Pasta for six ! Memory management ! CPU Scheduling – boil 1 quart salty ! I/O Management water CPU thread of execution – stir in the pasta – cook on medium until “al dente” input data – serve Process Program 29 30
Recommend
More recommend
