Chapter 3 - O/S Interface

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 rtis

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-1s 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 Macs?
• 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 isnt 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 programs 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 processs
  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 dont 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 argb3 gcc, prog1.cc, (char ) 0
  
• int pid1 CreateProcess(gcc, 3, argb)
• char argv3
• argv0 pico argv1 prog1.cc
• argv2 (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 ltiostream.hgt
• void main(int numArgs, char argStrings)
• int I
• for (I 0 I lt numArgs I)
• cout ltlt argStringsI ltlt
• cout ltlt \n

15

• Process Management SysCalls
• A child process can inspect the passed parameters
  from the parent process readily enough
• include ltiostream.hgt
• void main(int numArgs, char argStrings)
• int I
• for (I 0 I lt numArgs I)
• cout ltlt argStringsI ltlt
• cout ltlt \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, intbuf)
• 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)
• lt and gt use to re-direct standard input and
  output
• VERY useful abstraction if programmer uses stdin
  and stdout then the program doesnt require any
  specific input and output files!
• Pipe symbol () a shortcut for
• who gt who.out sort lt 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 its base influenced O/S ideas
• MS/DOS minimal operating system for basic PC
  (1980 vintage!) beware books 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
  shells role
• Basic structure of a shell accept user input,
  interpret either as internal or external command,
  if external then fork()/exec()/wait()