1. CS 149: Operating Systems January 29 Class Meeting Department of Computer Science San Jose State University Spring 2015 Instructor: Ron Mak www.cs.sjsu.edu/~mak

2. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 2 Example System Call: fork() #include main() { printf("Parent: Process started.\n"); printf("Parent: Forking a child.\n"); if (fork() != 0) { int status; printf("Parent: Waiting for child to complete.\n"); waitpid(-1, &status, 0); printf("Parent: Child has completed.\n"); printf("Parent: Terminating.\n"); } else { printf("Child: Process started.\n"); printf("Child: Start 10 second idle:"); int i; for (i = 10; i >= 0; i--) { printf("%3d", i); fflush(stdout); sleep(1); } printf(" done!\n"); printf("Child: Terminating.\n"); } Executed by the parent. Executed by the child. The two processes fork at this point. forktest.c

3. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 3 The waitpid() System Call  What are the parameters?  Use the command-line UNIX man (for “manual”) command to get documentation of any system command or API call. _ waitpid(-1, &status, 0); Demo Pass the address of variable status (i.e., pass by reference).

4. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 4 Shell: I/O Redirection  For a program run on the command line: Standard input (stdin) is the keyboard. Standard output (stdout) is the terminal. #include #define MAX_LENGTH 256 main(int argc, char *args[]) { char *progname = args[0]; char line[MAX_LENGTH]; while (gets(line) != NULL) { printf("%s: %s\n", progname+2, line); } This program reads lines of text from stdin and echos them to stdout after prepending each line with the program name. echo.c Why the +2 ?

5. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 5 Shell: I/O Redirection  You can redirect a program’s stdin on the command line with the < operator: Now the echo program will read its own source file.  You can redirect a program’s stdout on the command line with the > operator: Now the echo program will write to file echo.txt. Use the >> operator to append to an output file.  You can redirect both stdout and stdin../echo < echo.c./echo echo.txt Demo

6. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 6 OS Concept: Pipes  Pipes are a mechanism for interprocess communication (IPC). One process writes to one end of a pipe. Another process reads from the other end. Each process believes it is doing file I/O. Operating Systems: Design and Implementation, 3 rd ed. Andrew Tanenbaum & Albert Woodhull (c) 2006 Prentice-Hall, Inc. 0-13-142938-8

7. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 7 Shell: Piping  You can pipe a program’s output to another program with the | operator: The first program’s stdout becomes the stdin for the second program.  What’s the result of this command?./echo1 |./echo2./echo1 < echo.txt |./echo2 |./echo3 Demo

8. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 8 The POSIX Standard  POSIX (Portable Operating System Interface)  IEEE standard for system calls.  Maintain compatibility among operating systems. UNIX and non-UNIX

9. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 9 Process Management System Calls  POSIX system calls.  Most modern operating systems have system calls that perform these functions. However, details may differ. Modern Operating Systems, 3 rd ed. Andrew Tanenbaum (c) 2008 Prentice-Hall, Inc.. 0-13-600663-9 All rights reserved

10. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 10 File Management System Calls Modern Operating Systems, 3 rd ed. Andrew Tanenbaum (c) 2008 Prentice-Hall, Inc.. 0-13-600663-9 All rights reserved

11. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 11 File System Management System Calls Modern Operating Systems, 3 rd ed. Andrew Tanenbaum (c) 2008 Prentice-Hall, Inc.. 0-13-600663-9 All rights reserved

12. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 12 Miscellaneous System Calls Modern Operating Systems, 3 rd ed. Andrew Tanenbaum (c) 2008 Prentice-Hall, Inc.. 0-13-600663-9 All rights reserved

13. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 13 Kernel Mode vs. User Mode  An OS such as UNIX executes its critical system software in kernel mode. This is one way the OS protects itself.  As a user, you run utility programs (such as editors, compilers, and browsers) and application programs in user mode. System calls made by your programs can invoke some OS code that is executed in kernel mode.  On the command line, you can become “super user” and bypass some of the OS protection mechanisms.

14. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 14 Workflow of a System Call 1. Push nbytes 2. Push &buffer 3. Push fd 4. Invoke the read library routine. 5. Put the system call code for read in a register. 6. TRAP instruction switches to kernel mode to access the dispatcher in the OS kernel. 7. Dispatcher accesses the read handler. 8. Execute the read handler. 9. Return to the user program at the point after the TRAP instruction. Invoke the system call count = read(fd, buffer, nbytes) Operating Systems: Design and Implementation, 3 rd ed. Andrew Tanenbaum & Albert Woodhull (c) 2006 Prentice-Hall, Inc. 0-13-142938-8

15. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 15 Operating System Structure  There are various ways to organize the code of an operating system. Monolithic Layered Virtual machines Client-server Distributed _

16. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 16 OS Structure: Monolithic  The original classic way an OS was designed.  No structure. A collection of routines. Each routine can call any other routine. No information hiding.  A challenge to build and link.  An even bigger challenge to maintain and debug. Every software engineer should read the book The Mythical Man-Month about the development of IBM OS/360.

17. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 17 OS Structure: Layered  Organize the OS as a hierarchy of layers. Each layer built on top of the one below it. Operating Systems: Design and Implementation, 3 rd ed. Andrew Tanenbaum & Albert Woodhull (c) 2006 Prentice-Hall, Inc. 0-13-142938-8

18. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 18 OS Structure: Layered  Layers of the THE operating system. For a Dutch computer in the late 1960s. The bottommost layer 0 provided multiprogramming. _ Operating Systems: Design and Implementation, 3 rd ed. Andrew Tanenbaum & Albert Woodhull (c) 2006 Prentice-Hall, Inc. 0-13-142938-8

19. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 19 OS Structure: Virtual Machines  Virtual machines (VMs) were first developed for the IBM 370 in the late 1960s. Each virtual machine behaves like a separate physical machine. Controlled by a virtual machine monitor. Operating Systems: Design and Implementation, 3 rd ed. Andrew Tanenbaum & Albert Woodhull (c) 2006 Prentice-Hall, Inc. 0-13-142938-8

20. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 20 OS Structure: Virtual Machines  Modern VM monitors include: VirtualBox VMware KVM OpenVZ Xen

21. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 21 OS Structure: Client-Server  Put as much OS code as possible outside of the kernel and into user space.  OS services run as separate processes. Processes send messages to each other to request services. A “microkernel” serves as the communications bus. Operating Systems: Design and Implementation, 3 rd ed. Andrew Tanenbaum & Albert Woodhull (c) 2006 Prentice-Hall, Inc. 0-13-142938-8

22. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 22 OS Structure: Distributed  Like client-server, except that server processes run on different machines on the network. Service request messages go over the network. User programs do not need to know where the services are provided. _ Operating Systems: Design and Implementation, 3 rd ed. Andrew Tanenbaum & Albert Woodhull (c) 2006 Prentice-Hall, Inc. 0-13-142938-8

23. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 23 Processes  A process is basically an abstraction of a running program. The most central concept in any operating system.  Each process runs in its own address space. _

24. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 24 Process Models  Multiprogramming with multiple programs.  One program counter per CPU.  Each program has its own virtual CPU.  The real CPU rapidly switches from one program to another. Process switching AKA context switching Operating Systems: Design and Implementation, 3 rd ed. Andrew Tanenbaum & Albert Woodhull (c) 2006 Prentice-Hall, Inc. 0-13-142938-8

25. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 25 Process Models, cont’d  Only one program is active on a CPU at any instant. Operating Systems: Design and Implementation, 3 rd ed. Andrew Tanenbaum & Albert Woodhull (c) 2006 Prentice-Hall, Inc. 0-13-142938-8

26. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 26 Context Switching A process’s state information is kept in its process control block (PCB). Operating Systems: Design and Implementation, 3 rd ed. Andrew Tanenbaum & Albert Woodhull (c) 2006 Prentice-Hall, Inc. 0-13-142938-8

27. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 27 Process Creation  Principal events that cause processes to be created: System initialization. Execution of a process creation system call by a running process.  fork() A user request to create a new process. Initiation of a batch job.

28. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 28 Process Termination  Conditions that cause a process to terminate: Normal exit (voluntary). Error exit (voluntary). Fatal error (involuntary). Killed by another process (involuntary).  Cascading termination On some operating systems, when a process terminates, so do its child processes.

29. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 29 Process Creation and Termination What does the exec() system call do? Operating Systems: Design and Implementation, 3 rd ed. Andrew Tanenbaum & Albert Woodhull (c) 2006 Prentice-Hall, Inc. 0-13-142938-8

30. Computer Science Dept. Spring 2015: January 29 CS 149: Operating Systems © R. Mak 30 Process States  Running  Actually using the CPU at that instant.  Ready  Runnable, but temporarily stopped to let another process run.  Blocked  Unable to run until some external event happens. Operating Systems: Design and Implementation, 3 rd ed. Andrew Tanenbaum & Albert Woodhull (c) 2006 Prentice-Hall, Inc. 0-13-142938-8