Chapter 3 The Programming Interface Chien-Chung Shen CIS/UD

Introduction Chapter 2 studied the mechanisms used by OS kernel to implement the process abstraction – a process is a (running) instance of a program, where kernel provides a sandbox to safely execute untrusted code at user-level directly on the processor This chapter studies (1) how we choose to use the process abstraction what functionality does OS provide applications what functionality should go where – in kernel or in user-level library (2) how should OS itself be organized Programming interface and OS internal organization – A subset of programming interface for Unix (foundation of Linux, MacOS, iOS, and Android)

What Functions? (1) Process management – create, stop, resume, wait for processes; send asynchronous events Input and output – inter-process communications, communication with devices Thread management – create multiple threads with a process; synchronize their use of shared resources Memory management – share physical memory between processes File system and storage – store data persistently to survive machine crashes and disk failures; name and organize data

What Functions? (2) Networking and distributed systems – communicate with processes in other computers; coordinate between processes despite machine crashes and network problems Graphics and window management – control pixels on screen; make use of graphics accelerators Authentication and security – permission of user/program; know the user/program is who they say they are Focus on process management and input/output with ~12 system calls (which are immortal from the original Unix design in early 1970’s) p

Where Should They Go? Where can they be implemented? – user-level programs (e.g., shells) – user-level library (linked in with programs; e.g., UI widgets) – inside kernel (accessed via system calls; e.g., process management, file system, and networking stack) – user-level server (e.g., Window manager) Issues to consid er 1.flexibility 2.reliability 3.safety 4.performance

(1) Flexibility Easier to change OS code that is outside of kernel Not wise/easy to change system call interface Unix’s perspective: kernel as the thin waist – enabling innovation at both application-level and in hardware – e.g., Unix system call interfaces is simple, powerful, and portable

(2) Safety Resource management and protection are responsibility of OS kernel Protection can not be implemented in user-level library as applications can skip any checks made by the library

(3) Reliability Keep OS kernel minimal to improve reliability Kernel modules are not protected from one another e.g., microkernel design: isolate privileged, but less critical, parts of the OS, such as file system and window system, from the rest of kernel, into a set of user-level processes (or servers) accessed from user applications via IPC

(4) Performance Transfer control into kernel is more expensive than a procedure call to a library Transfer control to a user-level file system server via kernel is even more costly (argument against microkernel design)

Chapter Roadmap 3.1: system calls for process management 3.2: system calls for I/O and IPC 3.3 implementing a shell (user-level job control system) 3.4: how IPC works between client & server 3.5: how to use process abstraction to simply the structure of OS and make it more secure, reliable, and flexible

Process Management In batch processing system, kernel itself creates all processes Modern OS allows programs to create and manage their own processes – What are these programs? – Answers: window managers, web servers, shells, etc.

Shell A shell is a job control system – Allows programmer to create and manage a set of programs to do some task – Windows, MacOS, Linux all have shells Example: to compile a C program $ cc –c sourcefile1.c $ cc –c sourcefile2.c $ ln –o program sourcefile1.o sourcefile2.o

System Call Interface Processes management – fork, exec, wait I/O – open, read, write, close Communicating between processes (IPC) – pipe, dup, select, connect

To Create a Process “System call” to create a new process to run a program needs to – Create and initialize the process control block (PCB) in the kernel – Create and initialize a new address space – Load the program into the address space – Copy arguments into memory in the address space – Initialize the hardware context to start execution at “start” – Inform the scheduler that the new process is ready to run

Windows CreateProcess API (simplified) if (!CreateProcess( NULL, // No module name (use command line) argv[1], // Command line NULL, // Process handle not inheritable NULL, // Thread handle not inheritable FALSE, // Set handle inheritance to FALSE 0, // No creation flags NULL, // Use parent's environment block NULL, // Use parent's starting directory &si, // Pointer to STARTUPINFO structure &pi ) // Pointer to PROCESS_INFORMATION structure ) Simple in theory, but complex in practice!

Unix Process Management Unix fork – system call to create a copy of the current (parent) process, and start it (child) running - no arguments! Unix exec – system call to change the program being run by the current process Unix wait – system call to wait for a process to finish Unix signal – system call to send a notification to another process

Unix Process Management Parent Child Set up context [priority and I/O] for the program that is about to be started (e.g., close some files, open others, reduce priority, etc.) Is this safe (can this be trusted)? Bring the new executable image into memory and start it running

What does this code print? int child_pid = fork(); // no argument if (child_pid == 0) { // I'm the child printf("I am process #%d\n", getpid()); return 0; } else { // I'm the parent printf("I am parent of process #%d\n", child_pid); return 0; }

Implementing Unix fork Steps to implement Unix fork – Create and initialize the process control block (PCB) in the kernel – Create a new address space – Initialize the address space with a copy of the entire contents of the address space of the parent – Inherit the execution context of the parent (e.g., any open files) – Inform the scheduler that the new process is ready to run

Implementing Unix exec Steps to implement Unix exec – Load the program into the current address space – Copy arguments into memory in the address space – Initialize the hardware context to start execution at “start”

Unix wait Usually parent needs to pause until child complete – e.g., shell Background process ( & ) – parent does not wait

Questions Can Unix fork() return an error? Why? – answer answer Can Unix exec() return an error? Why? – answer Can Unix wait() ever return immediately? Why? – answer

Unix I/O Uniformity – All operations on all files and devices use the same set of system calls: open, close, read, write Open before use – Open returns a handle (file descriptor) for use in later calls on the file Byte-oriented Kernel-buffered read/write Explicit close – To garbage collect the open file descriptor

Unix File System Interface Unix file open is a Swiss Army knife: – Open the file, return file descriptor – Options: If file doesn’t exist, return an error If file doesn’t exist, create file and open it If file does exist, return an error If file does exist, open file If file exists but isn’t empty, nix it then open If file exists but isn’t empty, return an error …

Interface Design Question (1) open() has an option to create a file if it does not exist Why not separate system calls for open/create/exists as follows? if (!exists(name)) create(name); // can create fail? fd = open(name); // does the file exist? In multi-user system, files may be created/deleted in between the calls

Interface Design Question (2) Unix has the all-purpose atomic open() Because system calls are implemented in kernel, I/O system calls are made non-interruptible with respect to other system calls If another user tries to delete a file while the kernel is executing an open system call on the same file, the delete will be delayed until the open completes The open will return a file descriptor that will continue to work until the application closes the file The delete will remove the file from the file system, but the file system does not actually reclaim its disk blocks until the file is closed ls –li find. –inum

Implementing a Shell char *prog, **args; int child_pid; // Read and parse the input a line at a time while (readAndParseCmdLine(&prog, &args)) { child_pid = fork(); // create a child process if (child_pid == 0) { exec(prog, args); // I'm the child process, // run “prog” // NOT REACHED } else { wait(child_pid); // I'm parent, wait for child return 0; }