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 syscallvoid open(char *file_name) {

asm {

load ReadSystemCallNumber,r8

move file_name,r9

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: CreateProcess(), Exit(), Wait()

• InterProcess Communication (IPC) System calls: CreateMessageQueue(), SendMessage(), ReceiveMessage(), DestroyMessageQueue()

• 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

• 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 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

• 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 COM1: or LPT1: 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: Program Process

Exists in Disk Space Memory Space & CPU Time

Is Static Dynamic

Consists of Instructions Executing instructions

• 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

• 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();

• 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);

• 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”;

}

• 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”;

}

• 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

• 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

• 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 forwho > 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: 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)

• 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)

• 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()