Understanding System Calls and File Operations in Operating Systems

1. 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

2. 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 ReadSystemCallNumber,r8 move file_name,r9 syscall } }

3. 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

4. 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: CreateProcess(), Exit(), Wait() • InterProcess Communication (IPC) System calls: CreateMessageQueue(), SendMessage(), ReceiveMessage(), DestroyMessageQueue()

5. 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( name,flags) Create open file fid = creat( name,mode) Create file count = read( fid,buf,cnt) Read bytes count = write( fid,buf,cnt) Write bytes offset = lseek( fid,offset,m) Position in file code = close( fid) Disconnect code = unlink( name) Remove file

6. 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!

7. 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 fileHandle, StatStruct *statInfo) • Actual UNIX stat() call is documented on xi via “man -s 2 stat”; lots of interesting file meta-info • UNIX “chmod” command and “chmod(2)” (note use of “2” to indicate which man section) can change some of the UNIX meta-info

8. 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.

9. 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 COM1: or LPT1: device under DOS

10. 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: Program Process Exists in Disk Space Memory Space & CPU Time Is Static Dynamic Consists of Instructions Executing instructions

11. Process Management SysCalls • No argument forms: • int SimpleCreateProcess(char *programName); • Creates a process and returns a system-unique process ID (PID) (another UNIX-ism) • void SimpleExit(void); • SimpleExit() effectively ends the process’s execution and releases resources • void SimpleWait(int pid); • SimpleWait() will wait for the process with the specified PID to perform a SimpleExit() • Notice implicit “parallel” execution

12. Process Management SysCalls (sample) • Abbreviated Simple Create Process (error checking removed for simplicity; don’t you dare code without it!) int pid1 = SimpleCreateProcess(“gcc”); int pid2 = SimpleCreateProcess(“pico”); SimpleWait(pid1); SimpleWait(pid2); SimpleExit();

13. Process Management SysCalls (sample) Code sample with argument passing: char *argb[3] = { “gcc”, “prog1.cc”, (char * ) 0 }; int pid1 = CreateProcess(“gcc”, 3, argb); char *argv[3]; argv[0] = “pico”; argv[1] = “prog1.cc”; argv[2] = (char *) NULL; int pid2 = CreateProcess(“pico”, 3, argv); int ret1 = Wait(pid1); // ret1= Exit() val from pid1 int ret2 = Wait(pid2); // ret2 = Exit() val from pid2 Exit(0);

14. Process Management SysCalls • A child process can inspect the passed parameters from the parent process readily enough: #include <iostream.h> void main(int numArgs, char *argStrings[]) { int I; for (I = 0; I < numArgs; ++I); cout << argStrings[I] << “ “; } cout << “\n”; }

15. Process Management SysCalls • A child process can inspect the passed parameters from the parent process readily enough: #include <iostream.h> void main(int numArgs, char *argStrings[]) { int I; for (I = 0; I < numArgs; ++I); cout << argStrings[I] << “ “; } cout << “\n”; }

16. InterProcess 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

17. InterProcess Communication (IPC) • SOS System calls for IPC: • int CreateMessageQueue() • int SendMessage(int qID, int *buf) • void ReceiveMessage(int qID, int*buf) • int DestroyMessageQueue(int qID) • 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

18. 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

19. 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

20. 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

21. Operating System examples • UNIX: 1st 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, FreeBSD) • 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)

22. Operating System examples • Windows, Windows95, OS/2, WindowsNT: GUI-based O/Ses that to some degree succeed at providing traditional O/S services -- dominant O/Ses in terms of machine count • MacOS: 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)

23. 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()