Operating Systems

1
Operating Systems

• Components, Key Concepts, Structure

2
The Von Neuman Machine
Control Unitreads/decodes. Contains Pgm Ctr,
Instr. Reg. ALUexecutes. Contains various status
registers that signal the result of an
instruciton reg. that hold results MemoryStores
program data DeviceCommunicates with the
outside world
3
Fetch/Execute Cycle

• pc ROM Start Address
• ir memorypc
• hltflg unset
• while (hltflg unset)
• pc
• execute(ir)
• ir memorypc
• Initially ROM Start Address is the start address
  of the boot strap loaderpgm that stores the
  nucleus of the o/s
• Once loaded, computer is under the control of the
  o/s

4
I. Process Management

• More than one process can be associated with a
  single program
• Each is a separate execution sequence
• All processes can potentially execute
  concurrently
• O/S Tasks
• Creation/Deletion of processes
• Suspension and resumption of processes
• Process synchronization
• Interprocess communication
• Deadlock detection

5
I. Process Management

• Process? a program in execution
• Could be
• User program
• Compiler
• Text editor
• o/s itself

6
II. Memory Management

• Memory
• Array of words or bytes, each with its own
  address
• Loosely speaking, the only storage device the CPU
  can address directly (forgetting about cache)
• Many programs are in memory at the same time
• O/S Tasks
• Keep track of which pieces of memory are being
  used and by whom
• Decide which processes are to be loaded into
  memory
• Allocate/deallocate memory to processes

7
III. File System Management

• Provides a uniform logical view of information
  storage
• O/S Tasks
• Creation/Deletion of files
• Creation/Deletion of directories
• Map files onto secondary storage
• Backup files onto stable media

8
IV. Protection

• Ensure that these can only be manipulated by
  processes with proper authority
• Files
• Memory
• CPU

9
I/O Device Management

• Many Kinds of devices
• Each connected to the buses through a device
  controller
• Interface between the device controller and the
  device is standard and known to manufactures of
  the devices
• E.g. the SCSI interface or the IDE interface
• Not important to the programmer
• What is important
• Interface between the controller and software
• Defines how software manipulates the controller
  to cause the device to perform i/o
• Used by the device driver

10
Hypothetical Controller
Command Reg
Status Reg
logic
memory

• Suppose both are 0
• Software places command in Command Register to
  activate
• Software places data in memory
• Busy is set to 1
• Write command causes data to be written to device
• When complete, done flg is set, busy flag is
  unset
• Repeat

• Status has 2 flags busy, done
• Busy Done Meaning
• 0 0 idle
• 0 1 finished
• 0 working
• 1 1 not used

11
Interrupts

• Issue CPU, through the driver, may not write to
  a device whose busy flag is set.
• Solution 1
• CPU periodically polls the flags. Called
  busy-wait. Problem Process is using the CPU, but
  CPU is waiting for device to comlete (wastes
  processor cycles)
• Solution 2
• Device notifies processor when it completed an
  operation (called an interrupt)

12
Interrupt Technique

• Incorporate an interrupt flag in hardware
• Control unit checks interrupt flag during each
  fetch/execute cycle
• while (hltflg unset)
• ir memorypc
• pc
• execute(ir)
• if (interrupt requested)
• interrupt hardware saves context for
  currently running process
• interrupt hardware looks in pre-defined place
  for address of interrupt handler
• branch to software interrupt handler
  which starts/controls device.
• invoke scheduler
• Invoke O/S assembly language routine to
  start chosen process

13
Interrupt Hardware

• Saves process context
• Determines which device signaled the interrupt
• Branch to appropriate interrupt handler (part of
  the device driver)
• Completing causes done/busy flags to be unset.
• Invokes scheduler to resume a process.

14
Problem

• What if the interrupt is interrupted race
  condition
• A little help from hardware
• Interrupt enable flag
• Disable interrupts when an interrupt is being
  serviced.

15
Drivers

• Software interface between the device controller
  and the o/s
• Goals
• Simplify the driver
• Enable CPU and devices to operate in parallel
• So, device driver is the entity that controls
  cpu-i/o parallelism

16
Overview
Disk
2
Disk Controller
4
Interrupt Controller Chip
CPU
3
6,7,8
5

• Driver writes to controller registers
• Controller starts device
• When operation is finished, controller interrupt
  controller chip
• Interrupt controller asserts flag on CPU
• Interrupt controller gives device number to CPU
• Context of current process is saved
• Device number is used as an index into memory to
  find the interrupt handler for the device. Gets
  data from device controller memory and writes to
  main memory.
• When interrupt is complete, scheduler is invoked.

1
17
VI. Command Interpreter

• Programmer interface to the o/s, though, strictly
  speaking, not part of the o/s itself.
• Unix?called the shell
• Logging on creates a process on your behalf
• indicates waiting for input
• Issue a command (e.g., cp), shell starts a child
  process? called a system call
• We can think of a GUI as an easier-to-use shell
• Like the shell, a program running on top of the
  o/s

18
Shell Continued

• Issue a command
• Say, cp file1 file2
• Shell starts a child process
• Called a system call
• Shell waits until o/s completes task
• These can become almost arbitrarily complex
• cat f1 f2 f3 sort gt f4
• Following shell with causes process to run in
  the background
• sort lt f4 f5

19
System Calls

• Provides an interface between a running program
  and the o/s
• To be distinguished from the shell. System calls
  occur within a program
• Every subsystem of the o/s has its own set of
  system calls

20
System Call ExampleFile Management

• include ltstdio.hgt
• include ltfcntl.hgt
• include ltsys/stat.hgt
• int main(int argc, char argv)
• int inFile, outFile
• int len char ch
• if (argc ! 3)
• printf("Usage copy ltf1gt ltf2gt\n")
• exit(1)
• inFile open(argv1, O_RDONLY)
• outFile open(argv2, O_WRONLY O_CREAT,
  S_IRWXU)
• while ((len read(inFile, ch, 1)) gt 0)
• write(outFile, ch, 1)
• close(inFile)

21
Example

• Program has control of the CPU and wants to read
  a file
• Pushes how much to read, address of read buffer,
  file descriptor for file to be read onto the
  stack
• Issues read system call, putting the read code in
  a place where the o/s expects it.
• Issue a trap instruction to give control to o/s
• Read is dispatched and does its work through the
  system call handler
• o/s returns from trap to give control to library
  procedure that invoked the system call
• Library procedure returns control to calling
  program
• Calling program increments the stack pointer and
  is free to execute the next instruction

22
System Call Example Processes

• Processes are created through other processes
• As early as 1963, researchers postulated 3
  process creation functions
• fork() create a process
• join() merge two processes
• quit() terminate a process

23
Primary Issue

• How to get two processes that access common
  memory to behave in an orderly fashion
• Called the Critical Section Problem
• B should not be allowed to retrieve x until A has
  finished update
• procA procB
• while(true) while(true)
• update(x) retrieve(x)
• 
  
• retrieve(y)
  update(y)
• 
  
• 
  
• 
  

24
In Unix

• fork()
• Creates a copy of the current process but in its
  own address space
• excve()
• Allows a process to reload its address space with
  another program
• wait()--Lets a parent process suspend itself
  until a child terminates

25
Parents and Children

• Process that calls fork() parent
• Process created child
• Child is a duplicate of the parent, including all
  file descriptors and registers
• Child is separately scheduled
• All data is identical at the time of creation,
  but changes in one do not affect the otherthey
  have separate address spaces
• How is this useful?

26
execve

• Entire core image is replaced by the file named
  in its first parameter
• See parent.c and child.c on the website
• Two important system calls
• ps u ltusergt
• kill -9 ltpidgt

27
Other Typical System Calls

• kill -9 (pid)
• S time(seconds)

28
Operating System StructureMonolithic Systems

• Entire o/s runs as a single program in user mode
• o/s is a collection of procedures linked into a
  single executable
• Leads to unwieldy but efficient code
• Mode of operation
• Invoke system call by putting parameters in a
  well-defined place
• Execute a trap, switching machine to kernel mode
• o/s fetches parameters and determines which
  system call to carry out
• o/s indexes into a table indicated by one of the
  parameters that contains a pointer to the
  procedure that carries out the system call
• Return to calling program

29
Operating System StructureLayered Systems

• o/s is organized as a hierarchy of layers
• Earliest such system THE, Dijkstra, 1968
• Layer Name Desc.
• 5 Operator Shell
• User Programs User programs with nice
  interface to layer 3
• I/O mgmt manage i/o devices and buffer
  information streams
• Operator/process above this layer each process
• communication had its own console
• Memory mgmt Allocated memory for processes.
• Above this level, memory is an abstraction
• 0 Processor allocation Took care of
  multiprogramming. Above this layer, processes
  did not have to worry that multiple processes
  were running on a single processor

30
Microkernel

• Code is buggy. Roughly 10 bugs per 1000 lines of
  code for industrial systems. To make things more
  manageable
• Split the o/s into small, well-defined modules
• Only one of which runs in kernel mode.
• The rest run as ordinary user processes
• Found mostly in real-time industrial and military
  applications

31
Minix 3

• Probably the best-known microkernel o/s
• Microkernel
• 3200 lines of C
• --800 lines of assembler for catching interrupts
  and switching processes
• User Mode
• Device drivers
• Servers (process manager, file system)
• User programs

32
Mechanism vs. Policyin Microkernel

• Separation of policy and mechanism kernel has
  the mechanism to perform low level operations.
  The policy is elsewhere
• Example Scheduler
• Priorities are assigned to processes in user mode
• Microkernel manages the priority queue and
  availability of processor

33
Virtual O/S

• Late sixties, IBM developed VM/370
• Basic insight two tasks of o/s can be separated
• Allocation of resources (e.g., multiprogramming)
• More convenient interface
• System was layered

CMS
CMS
CMS
VM/370
IBM 370
34
Extension

• VM/370 called a type 1 hypervisor
• Problems developed with the x86 chip, having to
  do with issuing privileged instructions from
  outside the kernel (e.g., from CMS)
• Led to a another kind of virtual machine called a
  type 2 hypervisor
• Runs on a host o/s which runs on hardware
• Guest o/s runs on the hypervisor
• But how does guest o/s run privileged
  instructions?
• Hypervisor translates code of guest o/s block by
  block, replacing with hypervisor calls (which in
  turn make calls to the host o/s)

35
Formal Definition of Virtualization

• Gerald J. Popek and Robert P. Goldberg (1974).
  "Formal Requirements for Virtualizable Third
  Generation Architectures". Communications of the
  ACM 17 (7) 412 421.