1. Processes Introduction to Operating Systems: Module 3

2. System Calls u System calls provide the interface between a running program and the operating system  Generally available as assembly-language (trap) instructions  Languages defined to replace assembly language for systems programming allow system calls to be made directly u Methods used to pass parameters to the operating system  Pass parameters in registers  Store the parameters in a table in memory, and the table address is passed as a parameter in a register  Push (store) the parameters onto the stack by the program, and pop off the stack by operating system

3. System Design Goals u User goals – operating system should be convenient to use, easy to learn, reliable, safe, fair, and fast u System goals – operating system should be easy to design, implement, and maintain, as well as flexible, reliable, error-free, and efficient  System goals and user goals may conflict  efficiency vs. fairness  easy vs. flexible

4. System Structure – Layered Approach u The operating system is divided into a number of layers or levels, each built on top of lower layers. The lowest layer is the hardware; the highest is the user interface. u Layers are selected such that each uses functions and services of only lower-level layers.

5. An Operating System Layer Functions implemented at layer M layer M layer M -1 Functions hidden by layer M Functions passed by layer M

6. Monolithic vs. Microkernel OS u Monolithic  Every thing resides in the kernel  process and memory management  Interrupts, I/O, device drivers, file systems  Networking  Other functions and system calls  The Kernel is big  Everything is part of every application's address space Process in a monolithic OS OS KERNEL Process mngmt Memory mngmt I/O File systems Networking Interrupts All system calls App1 code Shared Libraries App1 Stack App1 data Not used BIG

7. Monolithic vs. Microkernel OS u Microkernel  The kernel contains code for the most basic OS services  All other OS services are provided by separate processes running in user space  Can modify components while system is running, don’t need to recompile to change a driver or other component  kernel, drivers export function tables to each other so they can interact Microkernel Client Microkernel File Server Microkernel Memory Server Microkernel Client Message from client to server

8. Mechanisms and Policies u Mechanisms determine how to do something, policies decide what will be done u The separation of policy from mechanism is a very important principle: it allows maximum flexibility if policy decisions are to be changed later u Micro-kernel design supports this separation  Easy to replace system components u Monolithic design encourages combined mechanism and policy at a low level

9. Unix System Structure u The UNIX OS consists of two 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 OS functions

10. Windows Architecture u Interaction among executive components similar to a microkernel system  But not all components run as user level services u Executive components communicate by passing messages through a component called the kernel u Hardware abstraction layer (HAL) maps generic hardware interaction to specific platforms. HAL isolates the kernel from architecture-specific details.

11. Windows Architecture

12. What is a Process u A program in execution u A sequentially executing piece of code that runs on one processing unit of the system u An asynchronous computational activity (i.e., it proceeds at its own pace, independent of another process) u The locus of control of a program in execution u A process is:  an encapsulation of program, data, resources and a virtual processor  controlled and supported by the underlying OS kernel  Which can interact with other processes and I/O devices through the OS kernel

13. The System View of Processes u Processes are an abstraction  The computer hardware executes instruction  Instructions are grouped into multiple programs in execution by software constructs u Processes do not exist when the computer starts  The instructions initially run set up the data structures needed to implement the process abstraction  The operating system is responsible more maintaining the data structures that implement the process model  The OS needs a system that supports exceptions to do this

14. In the Beginning u Hardware defines a location from which the initial instruction is fetched after system start-up  This bootstrap program loads the operating system code and initializes operating system data  Then “real” processes can be created  Though the process abstraction is not yet defined when it runs, the bootstrap program can be viewed as the initial process

15. Address Space u In the process abstraction, an address space is more than just memory  Inter-process communication objects  Files  Other resources u Any entity which can be referenced by a process is part of its address space

16. Program (text) Data (global variables) Stack (temporary data) Heap (dynamic memory) Inter-process Communication File & I/O Operations System Calls OS/Kernel The operating system can handle all interaction between a process and other system entities; each communication requires a system call Process-OS interaction

17. Program (text) Data (global variables) Stack (temporary data) Heap (dynamic memory) Inter-process Communication File & I/O Operations System Calls OS/Kernel The operating system can set up communication channels between a process and other system entities; once the channel is established, further interaction does not require a system call Process-OS interaction

18. A UNIX Process Abstract Machine Environment Program Text Stack Process Status Data Resources Files Object instructions Static variables Temporary variables a.out

19. Listing unix processes u list processes (Solaris 2): u ps — my processes, little detail u ps -l — my processes, more detail u ps -al — all processes, more detail miller.cs: ps -l F UID PID PPID %C PRI NI SZ RSS WCHAN S TT TIME COMMAND 8 1004 16628 16626 0 58 20 1724 1200 ??? S pts/103 0:00 -csh 8 1004 16780 16628 3 58 20 1264 724 ??? S pts/103 0:03 find / 8 1004 16884 16882 0 58 20 1724 1200 ??? S pts/108 0:00 -csh

20. Process states terminated ready waiting running terminate block dispatch pre-empt wakeup inactive create activate suspend