Post on 20-Jan-2016
description
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()