Chapter 3 OS Interface System Calls detailed flow

Chapter 3 - O/S Interface • System Calls - detailed flow of control (Figure 3. 1) – Program executes syscall – CPU handles the interrupt (save psw & ia; disable interrupts & flip to system mode; jump to appropriate iva address for syscall) – System call handler (aka the Operating System) performs the system call and rti’s

• System Calls (continued) – A system call is similar to a procedure/function call in a traditional programming language, except a change in protection context occurs (user to system mode; perform call; system to user upon return) – How to make a syscall void open(char *file_name) { asm { load Read. System. Call. Number, r 8 move file_name, r 9 syscall } }

• System Calls (continued) – Result of the system call return back in register 1 • System Call Interface (The “API” provided by the operating system) – Set of “instructions” that extend the native hardware via the virtual computer supported by the operating system – A workable definition of an operating system: the complete set of system calls that are provided – The system call interface is the description of the set of syscalls

• CRA-1’s System calls – Modeled after UNIX system calls (for a complete list on Solaris 2. 5. 1, try typing “man -s 2 intro” on xi. cs. fsu. edu) – Simplified subset of common system calls broken down into three areas: • File and I/O System calls: open(), creat(), read(), write(), lseek(), close(), unlink(), and stat() • Process Management System calls: Create. Process(), Exit(), Wait() • Inter. Process Communication (IPC) System calls: Create. Message. Queue(), Send. Message(), Receive. Message(), Destroy. Message. Queue()

• Hierarchical File Naming Systems – Should be obvious to all of us now! – Figure 3. 2 example of an HFS – Note difference between UNIX-style delimiter (“/”) and DOS-style (“”); anybody know Mac’s? • File & I/O System Calls (very UNIX-like) fid = open( fid = creat( count = read( count = write( offset = lseek( code = close( code = unlink( name, flags) Create open file name, mode) Create file fid, buf, cnt) Read bytes fid, buf, cnt) Write bytes fid, offset, m) Position in file fid) Disconnect name) Remove file

• Note typical use of I/O system calls in Figure 3. 3 • file - passive container of data; a named sequence of bytes • open file - active sources and sinks for data • Notice the “behind the scenes” data management that occurs with an open file • Figure 3. 4 & 3. 5 relate the objects and operations on those objects within an operating system • Trace the File Copy & Reverse programs as well as arrow-happy Figure 3. 6!

• File meta-information - information about the file that isn’t in the file, such as: – Owner, permissions, timestamps, size, etc. – Try an “ls -l” on a typical UNIX file – CRA-1 O/S has a UNIX-style stat() syscall: int stat(int file. Handle, Stat. Struct *stat. Info) – Actual UNIX stat() call is documented on xi via “man -s 2 stat”; lots of interesting file meta-info – UNIX “chmod” command “chmod(2)” (note use of “ 2” to indicate which man section) can change some of the UNIX meta-info

• Turns out the file naming conventions and access methods (I/O system calls) are a useful abstraction for accessing all sorts of objects, including: files, directories, terminals (keyboard, mouse, etc. ), disk, process information (see “man proc”), etc. • UNIX device files (OS objects treated as file objects) traditionally are created and managed in the directory /dev. Try an “ls -l” of /dev sometime! Device file naming conventions are as varied as UNIX implementations, unfortunately.

• Unifying devices and files into a common namespace and using the same set of I/O system calls for all these objects results in device independent programming • Note that other operating systems provide device independent mechanisms, such as the COM 1: or LPT 1: device under DOS

• Process - a fundamental operating system object – Process is an instance of a program’s execution – Process is the execution of a program on a virtual computer – Process is a set of OS objects that have their own memory space (code, data, stack), register set and process table entry • Program (executable binary) vs Process: Exists in Is Consists of Program Process Disk Space Static Instructions Memory Space & CPU Time Dynamic Executing instructions

• Process Management Sys. Calls – No argument forms: • int Simple. Create. Process(char *program. Name); – Creates a process and returns a system-unique process ID (PID) (another UNIX-ism) • void Simple. Exit(void); – Simple. Exit() effectively ends the process’s execution and releases resources • void Simple. Wait(int pid); – Simple. Wait() will wait for the process with the specified PID to perform a Simple. Exit() • Notice implicit “parallel” execution

• Process Management Sys. Calls (sample) – Abbreviated Simple Create Process (error checking removed for simplicity; don’t you dare code without it!) int pid 1 = Simple. Create. Process(“gcc”); int pid 2 = Simple. Create. Process(“pico”); Simple. Wait(pid 1); Simple. Wait(pid 2); Simple. Exit();

• Process Management Sys. Calls (sample) Code sample with argument passing: char *argb[3] = { “gcc”, “prog 1. cc”, (char * ) 0 }; int pid 1 = Create. Process(“gcc”, 3, argb); char *argv[3]; argv[0] = “pico”; argv[1] = “prog 1. cc”; argv[2] = (char *) NULL; int pid 2 = Create. Process(“pico”, 3, argv); int ret 1 = Wait(pid 1); // ret 1= Exit() val from pid 1 int ret 2 = Wait(pid 2); // ret 2 = Exit() val from pid 2 Exit(0);

• Process Management Sys. Calls – A child process can inspect the passed parameters from the parent process readily enough: #include <iostream. h> void main(int num. Args, char *arg. Strings[]) { int I; for (I = 0; I < num. Args; ++I); cout << arg. Strings[I] << “ “; } cout << “n”; }

• Process Management Sys. Calls – A child process can inspect the passed parameters from the parent process readily enough: #include <iostream. h> void main(int num. Args, char *arg. Strings[]) { int I; for (I = 0; I < num. Args; ++I); cout << arg. Strings[I] << “ “; } cout << “n”; }

• Inter. Process Communication (IPC) – Cooperating processes often need to send information between themselves – Two main “branches” of IPC - shared memory and message passing – SOS implements a simple message passing scheme using separate message queues (Figure 3. 12) that permits any arbitrary connections between processes – Notice at this level the IPC occurs within the same machine and O/S (no networking) – A real world example: “man msgop” on xi

• Inter. Process Communication (IPC) – SOS System calls for IPC: • • int Create. Message. Queue() int Send. Message(int q. ID, int *buf) void Receive. Message(int q. ID, int*buf) int Destroy. Message. Queue(int q. ID) – Sample Sender, Receiver & startup code on pps. 51 - 54. – Figure 3. 13 details control flow (dashed arrows) and data flow (solid arrows) between parent, sender child and receiver child processes

• UNIX-style Process Creation – UNIX uses two system calls to start up a different program • int fork() - create new process with a copy of current process’ memory, etc. • int execv(char *path, char** argv) - load up new binary into current process • void exit( int code) - exit current process and return an integer code • int wait(int *code) - wait for any child process to issue exit() and find out the exit() return code – Figure 3. 14 demonstrates fork() call

• More UNIX specifics – Concept of standard input (stdin or file descriptor 0), standard output (stdout or file descriptor 1), and standard error (stderr or file descriptor 2) – UNIX shell program interpret certain characters (metacharacters - chars with meanings other than their standard ASCII value) – < and > use to re-direct standard input and output – VERY useful abstraction; if programmer uses stdin and stdout then the program doesn’t require any specific input and output files! – Pipe symbol (“|”) a shortcut for who > who. out; sort < who. out who | sort

• Communicating with Pipes – A pipe combines best of message passing simplicity with file I/O semantics – Figure 3. 16: Allows for arbitrary sized messages, no explicit message queue management required – UNIX allows for both named (pipe is a file visible in the UNIX file system) and unnamed pipes – See “man pipe” for information on UNIX pipes

• Operating System examples – UNIX: 1 st widely-used O/S to be written almost entirely in a high-level language (C); basis for much O/S research and is the birthplace of much of the Internet tools; many versions exist, including some free ones (Linux, Free. BSD) – Mach: a microkernel-based O/S (small O/S that provides only a basic set of services); OSF/1 uses Mach as it’s base; influenced O/S ideas – MS/DOS: minimal “operating system” for basic PC (1980 vintage!); beware book’s use of the phrase “open system” (open here = no protection)

• Operating System examples – Windows, Windows 95, OS/2, Windows. NT: GUI -based O/Ses that to some degree succeed at providing traditional O/S services -- dominant O/Ses in terms of machine count – Mac. OS: Influential in OS & GUI integration design – MANY other operating systems exist for general and specific purposes! – MOST are influenced by the existence of Open Systems Standards (such as TCP/IP)

• The Shell game – Most users perceive the “Operating System” not through direct interaction with the kernel through system calls but rather through the command interpreter or shell program – The shell provides a user interface to the O/S; traditionally a non-GUI environment – Figure 3. 18: Level view and “onion layer” view of shell’s role – Basic structure of a shell: accept user input, interpret either as internal or external command, if external then fork()/exec()/wait()