COSC 4740

1. COSC 4740 Chapter 2 Operating System Structures

2. O/S Components • Process management • I/O management • Main Memory management • File & Storage Management • Networking/Communications • Protection and Error Detection • User interface • Varies between Command-Line (CLI), Graphics User Interface (GUI), Batch Command Interpreter

3. A View of Operating System Services

4. Process Management • Process (or job): A program or a fraction of a program that is loaded in main memory and executing. • We do not need the entire program code at once. To process an instruction, CPU fetches and executes one instruction of a process after another in the main memory.

5. Tasks of Process Management • Create, load, execute, suspend, resume, and terminate processes • Switch system among multiple processes in the main memory (process scheduling) • Provides communication mechanisms so that processes can send (or receive) data to (or from) each other (process communication). • Control concurrent* access to shared data to keep shared data consistent (process synchronization). • Allocate/de-allocate resources properly to prevent or avoid deadlock situation**

6. I/O Management • Motivations: • Provide the abstract level of H/W devices and keep the details from applications to ensure proper use of devices, to prevent errors, and to provide users with convenient and efficient programming environment. • Tasks of I/O Management of OS: • Hide the details of H/W devices • Manage main memory for the devices using cache, buffer, and spooling • Maintain and provide device driver interfaces

7. Main Memory management Process must be mapped to physical addresses and loaded into main memory to be executed. • Motivations: • Increase system performance by increasing “hit” ratio (e.g., optimum: when CPU read data or instruction, it is in the main memory always) • Maximize memory utilization • Tasks of Main Memory Management of OS: • Keep track of which memory area is used by whom. • Allocate/de-allocated memory as need

8. File & Storage Management • Motivation: • Almost everything is stored in secondary storage. Therefore, secondary storage access must be efficient (i.e., performance) and convenient (i.e., easy to program I/O function in application level) • Important data are duplicated and/or stored in ternary storage.

9. Tasks of File Management • Create, manipulate, delete files and directories  • Tasks of Storage Management • Allocate, de-allocate, and defrag blocks[1] • Bad block marking • Scheduling for multiple I/O request to optimize the performance

10. Networking/Communications • Allow communications between computers (more important for Client/Server OS and Distributed OS). • Communications may be via shared memory or through message passing (packets moved by the OS)

11. Protection and Error Detection • Protection • Hardware resources, Kernel code, processes, files, and data from erroneous programs and malicious programs. • Error detection • May occur in the CPU and memory hardware, in I/O devices, and in user program • For each type of error, OS should take the appropriate action to ensure correct and consistent computing • Debugging facilities can greatly enhance the user’s and programmer’s abilities to efficiently use the system

12. Command Interpreter • Command Interpreter is one of the most important system programs[1]. Because almost every OS provide system programs, some people argue that command interpreter is a part of OS. • Motivation: • Allow human users to interact with OS • Provide convenient programming environment to users

13. Tasks: • Execute a user command by calling one or more number of underlying system programs or system calls • Examples: • Windows DOS command window • Bash of Unix/Linux • CSHELL of Unix/Linux

14. System Calls • Programming interface to the services provided by the OS • Typically written in a high-level language (C or C++) • Mostly accessed by programs via a high-level Application Program Interface (API) rather than direct system call use • Three most common APIs are Win32 API for Windows, POSIX API for POSIX-based systems (including virtually all versions of UNIX, Linux, and Mac OS X), and Java API for the Java virtual machine (JVM) • Why use APIs rather than system calls?

15. Example of System Calls • System call sequence to copy the contents of one file to another file

16. Example of Standard API • Consider the ReadFile() function in the • Win32 API—a function for reading from a file • A description of the parameters passed to ReadFile() • HANDLE file—the file to be read • LPVOID buffer—a buffer where the data will be read into and written from • DWORD bytesToRead—the number of bytes to be read into the buffer • LPDWORD bytesRead—the number of bytes read during the last read • LPOVERLAPPED ovl—indicates if overlapped I/O is being used

17. Types of System Calls • Process control • File management • Device management • Information maintenance • Communications

18. System Call Implementation • Typically, a number associated with each system call • System-call interface maintains a table indexed according to these numbers • The system call interface invokes intended system call in OS kernel and returns status of the system call and any return values • The caller need know nothing about how the system call is implemented • Just needs to obey API and understand what OS will do as a result call • Most details of OS interface hidden from programmer by API • Managed by run-time support library (set of functions built into libraries included with compiler)

19. API – System Call – OS Relationship

20. Standard C Library Example • C program invoking printf() library call, which calls write() system call

21. API vs. System Call summary • An API is application programming interface • This are a set of standard functions that the program calls. • This API then call the specific System call for that specific O/S • A system call is specific to an O/S • The system call for an O/S may be different between versions • Different parameters, even different names.

22. Operating System Design and Implementation • Design and Implementation of OS not “solvable”, but some approaches have proven successful • Internal structure of different Operating Systems can vary widely • Start by defining goals and specifications • 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

23. Operating System Design and Implementation (Cont.) • Important principle to separate Policy: What will be done?Mechanism: How to do it? • Mechanisms determine how to do something, policies decide what will be done • The separation of policy from mechanism is a very important principle, it allows maximum flexibility if policy decisions are to be changed later

24. Simple Structure • MS-DOS – written to provide the most functionality in the least space • Not divided into modules • Although MS-DOS has some structure, its interfaces and levels of functionality are not well separated

25. MS-DOS Layer Structure

26. Monolithic (The big mass) O/S • OS is simply a collection of functions, which can call any other ones when needed. • One very big OS including everything (system calls, system programs, every managers, device drivers, etc) • Entire OS resides in main memory • Pros: • High performance • Easy to implement • Cons: • Difficult to debug, modify, and upgrade • Poor security, protection, and stability of OS

27. still large single program but internally broken up into layers providing different functionalities.   Information hiding between layers  Increased security and protection Easy to debug, test, and modify OS If one layer stops working, entire system will stop Example: System Calls Memory Management Process Scheduling I/O Management Device Drivers Mapping overhead between layers Difficult to categorize into layers Layered Approach

28. Layered Operating System

29. UNIX • UNIX – limited by hardware functionality, the original UNIX operating system had limited structuring. The UNIX OS consists of two separable parts • Systems programs • The kernel • Consists of everything below the system-call interface and above the physical hardware • Provides the file system, CPU scheduling, memory management, and other operating-system functions; a large number of functions for one level

30. UNIX System Structure

31. Microkernel System Structure • Moves as much from the kernel into “user” space • OS is made up of several separated/independent modules • kernel, FS, MM, etc and only kernel resides in main memory. • Kernel calls other modules as needed to perform certain tasks. • Benefits: • Easier to extend a microkernel • Easier to port the operating system to new architectures • More reliable (less code is running in kernel mode) • More secure • Detriments: • Performance overhead of user space to kernel space communication

32. Mac OS X Structure

33. Modules • Most modern operating systems implement kernel modules • Uses object-oriented approach • Each core component is separate • Each talks to the others over known interfaces • Each is loadable as needed within the kernel • Overall, similar to layers but with more flexible

34. Solaris Modular Approach

35. Virtual Machines • A virtual machine takes the layered approach to its logical conclusion. It treats hardware and the operating system kernel as though they were all hardware • A virtual machine provides an interface identical to the underlying bare hardware • The operating system creates the illusion of multiple processes, each executing on its own processor with its own (virtual) memory

36. Virtual Machines Cont. • Allow multiple different OS to run on a single machine. VM gives an illusion that the machine is at entire disposal of OS by providing each OS an abstract machine. • Pros: • Solve machine-OS-software compatibility issues. • Stable and Good for OS development and testing (If one OS fails, the other OS can continue to run) • Cons: • Complex to develop/implement • Poor performance (abstract layer, mapping overhead between layers, …)

37. Virtual Machines History and Benefits • First appeared commercially in IBM mainframes in 1972 • Fundamentally, multiple execution environments (different operating systems) can share the same hardware • Protect from each other • Some sharing of file can be permitted, controlled • Commutate with each other, other physical systems via networking • Useful for development, testing • Consolidationof many low-resource use systems onto fewer busier systems • “Open Virtual Machine Format”, standard format of virtual machines, allows a VM to run within many different virtual machine (host) platforms

38. Virtual Machines (Cont.) (a) Nonvirtual machine (b) virtual machine Non-virtual Machine Virtual Machine

39. VMware Architecture

40. The Java Virtual Machine

41. Client-Server • OS consists of servers, clients, and kernel. Kernel is very tiny and handles only the communication between the clients and servers. Both clients and servers run in user mode. • Pros: • Stable (If a server fails, the OS can still operate) • Small kernel • Cons: • Complex to develop/implement (servers run in user mode and can access resources through kernel) • Security problem because servers reside in user space.

42. Back to Design Goals • Efficiency and Convenience • Keep kernel adequately small • Too much functionality in kernel  low flexibility at higher level • Too little functionality in kernel  low functional support at higher level • Maximize the utilization, performance, and functionality of the underlying H/W resources • OS design is affected by H/W properties • OS design is affected by the type of system to design (e.g., Multiprogramming, Multi-tasking, Real-time, Distributed, .etc)

43. System Generation • We should configure OS for the underlying hardware when we install it (i.e., installing OS) • Approaches: • Modify the source code of OS and recompile it on the target machine • Pros: small OS size, We can tune the details for the H/W • Cons: Very difficult, less flexible for H/W upgrade

44. System Generation Cont. • Provide many pre-compiled modules (e.g., five different memory manager object files). When we install OS, select certain object modules and link them together accordingly. • Pros: easy to configure, flexible for H/W upgrade • Cons: big OS size, We cannot tune the very details for the H/W

45. System Boot • Operating system must be made available to hardware so hardware can start it • Small piece of code – bootstrap loader, locates the kernel, loads it into memory, and starts it • Sometimes two-step process where boot block at fixed location loads bootstrap loader • When power initialized on system, execution starts at a fixed memory location • Firmware used to hold initial boot code

46. Q A &