W4118 Operating Systems Interrupt and System Call

1
W4118 Operating Systems Interrupt and System Call

• Instructor Junfeng Yang

2
Logistics

• Room change 633 Mudd
• Homework 1 out, due Thu 2/5 at 409pm EST

3
Last lecture
User

• What is OS? Stuff between
• App view hw abstraction layer
• Sys view resource mgr
• What functionality in OS?
• Users hardware ? functionality
• Concepts
• Batching work on group of jobs, so can optimize
• Spooling overlap I/O with compute
• OS buffering, DMA, interrupt
• Multiprogramming keep N jobs in mem, OS chooses
  which to run
• OS job scheduling, mem mgmt
• Timesharing fast switch ? view of dedicated
  machine
• OS more complex scheduling, mem mgmt,
  concurrency control, synchronization

App
OS
HW
4
Today
User

• OS event-driven
• Device events interrupt
• Application events system call
• Interrupt
• Background
• How interrupt works
• Some tricky points
• System call

App
OS
HW
5
Computer Organization

• Computer-system operation
• One or more CPUs, device controllers connect
  through common bus providing access to shared
  memory

6
CPU

• CPU runs instructions
• while (fetch next instruction)
• run instruction
• Needs work space registers
• E.g. x86 has 8 general purpose registers EAX,
  EBX, ECX, EDX, ESI, EDI, EBP, ESP
• Very fast, very few
• Needs more work space memory
• CPU has address line, data line
• Sends out address on address line
• Data comes back on data line, or data is written
  to data line
• Instructions in memory too!
• IP instruction pointer (or Program Counter)
• Increment after running each instruction

7
CPUs fetch-execute cycle
User Program
Fetch instruction at IP
Decode the fetched instruction
IP
Execute the decoded instruction
Advance IP to next instruction
8
How to bootstrap this cycle?

• Where to find the first instruction?
• The boot process
• 1. When CPU powers up, IP always points to fixed
  memory address (0xfffffff0)
• 2. This memory address maps to ROM with BIOS
• 3. BIOS executes, initializes your computer
• 4. BIOS loads boot loader from first sector of
  disk (MBR) into RAM, then jump
• 5. Boot loader loads your kernel
• Can have two-level boot loader, or no boot loader

9
How do devices gain CPUs attention?
10
How do devices gain CPUs attention?

• I/O devices and the CPU can execute concurrently
• Device controller in charge of a device type
• Each device controller has a local buffer
• CPU moves data b/w main memory controller buffers
  (spooling)
• I/O b/w controller buffer and device
• Device controller informs CPU that it has
  finished its operation by causing an interrupt
• Controller buffer small, want better
  interactivity ? Want CPU to respond fast

11
CPUs fetch-execute cycle with interrupt
User Program
Fetch instruction at IP
Decode the fetched instruction
Save context
IP
Get INTR
Execute the decoded instruction
Lookup ISR
Advance IP to next instruction
Execute ISR
IRQ?
yes
IRET
no
12
Interrupt Hardware (legacy systems)
IRQs
x86 CPU
Master PIC (8259)
Slave PIC (8259)
Ethernet
INTR
SCSI Disk
Real-Time Clock
intr
Programmable Interval-Timer
Keyboard Controller

• I/O devices have (unique or shared) Interrupt
  Request Lines (IRQs)
• IRQs are mapped by special hardware to interrupt
  numbers, and passed to the CPU
• This hardware is called a Programmable Interrupt
  Controller (PIC)

13
The Interrupt Controller

• Responsible for telling the CPU when a specific
  external device wishes to interrupt
• Needs to tell the CPU which one among several
  devices is the one needing service
• PIC translates IRQ to interrupt number
• Raises interrupt to CPU
• Interrupt available in register
• Waits for ack from CPU
• Interrupts can have varying priorities
• PIC also needs to prioritize multiple requests
• Possible to mask (disable) interrupts at PIC or
  CPU
• Early systems cascaded two 8 input chips (8259A)

14
Example Interrupts on 80386

• 80386 core has one interrupt line, one interrupt
  acknowledge line
• Interrupt sequence
• Interrupt controller raises INT line
• 80386 core pulses INTA line low, allowing INT to
  go low
• 80386 core pulses INTA line low again, signaling
  controller to put interrupt number on data bus

15
CPUs fetch-execute cycle with interrupt
User Program
Fetch instruction at IP
Decode the fetched instruction
Save context
IP
Get INTR ID
Execute the decoded instruction
Lookup ISR
Advance IP to next instruction
Execute ISR
IRQ?
yes
IRET
no
16
Interrupt Descriptor Table

• The entry-point to the interrupt-handler is
  located via the Interrupt Descriptor Table (IDT)
• Interrupt Service Routine IDTInterrupt number
• Also called interrupt handler
• IDT is in memory, initialized by OS at boot
• How to locate base of IDT?
• CPU has a register, idtr, pointing to IDT,
  initialized by OS via the LIDT instruction at
  boot

17
Putting It All Together
Memory Bus
IRQs
PIC
intr
idtr
CPU
IDT
INTR
0
intr
ISR
Mask points
255
18
Some tricky points

• Must be able to resume user program after
  interrupt, so need to save instruction pointer
  and other registers
• Some done in hardware, some in handler
• To preserve IRQ order on the same line, must
  disable incoming interrupts (all or same line)
• Done in handler
• Thus, handler must run for a very short time
• Preempts what CPU was doing, which may be
  important
• Dont want to interrupt user program for long
• Dont want to disable interrupt for long
  (otherwise, may lose interrupts)
• Lead to some complex implementations. Well see
  in Linux

19
Interrupt v.s. Polling

• Instead for device to interrupt CPU, CPU can poll
  the status of device
• Intr I have a question.
• Poll While(1) Do you have a question?
• Good or bad?
• For mostly-idle device?
• For busy device?

20
Same Interrupt mechanism used for other unusual
control transfers

• Weve seen Interrupts raised externally by
  device
• Traps (or Exceptions) raised internally by CPU
• 0 divide-overflow fault
• 3 breakpoint
• 6 Undefined Opcode
• 13 General Protection Exception
• System call can be implemented this way too
• Linux system call INT 0x80

21
System calls

• Programming interface to OS services
• Next
• Protection
• System calls and application programming
  interface (API)
• How to implement system calls

22
The need for protection

• For reliability buggy or malicious user program
• Exceptions (division by 0, buffer overrun,
  dereference NULL, )
• Resource hogs (infinite loops, exhaust memory )
• Despite these, OS cannot crash, must serve other
  processes and users
• For security malicious user program
• Read/write OS or other processs data without
  permission
• OS must check, and check code cannot be tampered
• Must distinguish trusted (OS) and untrusted (user
  program)

23
Dual-mode operation

• Allows OS to protect itself and other system
  components
• User mode and kernel mode
• Mode bit provided by hardware
• Provides ability to distinguish when system is
  running user code or kernel code
• Some instructions designated as privileged, only
  executable in kernel mode
• If executed in user mode, exception
• X86 actually has 4 modes, but only 2 used
• To perform privileged operations, must transit
  into OS through well defined interfaces
• System calls
• Interrupt handlers too

24
Example transition system call

• Call changes mode to kernel
• int 0x80
• OS validates system call
• Return resets it to user
• iret

25
Example transition timer interrupt

• Timer to prevent infinite loop / process hogging
  resources
• Set interrupt after specific period
• Set up before scheduling process to regain
  control or terminate program that exceeds
  allotted time
• When interrupt occurs, switch from current
  process to another
• (slightly simplified)

26
System Calls and API

• Mostly accessed by programs via a high-level
  Application Program Interface (API) rather than
  direct system call use
• Example API Win32 API, POSIX API
• Why use APIs rather than system calls?
• Give OS some flexibility
• Can have non-standard or not-so-easy-to-use
  system call interface. Fix things up in libs
  (usually easier than fix in kernel)
• (Note that the system-call names used throughout
  this text are generic)

27
System Call Implementation

• Typically, a number associated with each system
  call
• System-call interface maintains a table indexed
  according to these numbers
• Similar to interrupt, but dispatched in software
• The system call interface invokes intended system
  call in OS kernel and returns status of the
  system call and any return values
• Apps only need to know API, not system call
  interface

28
API System Call OS Relationship
printf(hello world!\n)
libc
User mode
eax sys_write int 0x80
syscalls table
system_call() fn syscallseax
kernel mode
IDT
0x80
sys_write() // do real work
29
System Call Parameter Passing

• Often, more information is required than simply
  identity of desired system call
• Exact type and amount of information vary
  according to OS and call
• Three general methods used to pass parameters to
  the OS
• Simplest pass the parameters in registers
• In some cases, may be more parameters than
  registers
• Parameters stored in a block, or table, in
  memory, and address of block passed as a
  parameter in a register
• This approach taken by Linux and Solaris
• Parameters placed, or pushed, onto the stack by
  the program and popped off the stack by the
  operating system
• Block and stack methods do not limit the number
  or length of parameters being passed

30
Parameter Passing via Table
31
Types of System Calls

• Process control
• File management
• Device management
• Information maintenance
• Communications

32
Case study the shell (simplified)

• Shell interactive command line interface
• User types command, shell executes
• Thus, need to create process to run command

while (1) write (1, " ,
2) parse_cmd (command, args) // parse
user input switch(pid fork ())
case -1 perror (fork) break
case 0 // child
execv (command, args, 0)
break default //
parent wait (0) break // wait for
child to terminate
33
Case study the shell (cont.)

• System calls for files open, read, write, close
• Identify opened file with file descriptors,
  numbered starting from 0
• Avoid repeated path resolution
• OS knows when file is closed ? can reclaim
  resource
• Avoid race same name may map to different file
• Naming conventions
• fd 0 input (e.g. keyboard)
• parse_cmd read(0, buf, bufsize)
• fd 1 output (e.g. screen)
• Write(1, hello\n, strlen(hello\n)
• Often use libc function (printf, fprintf, etc)
• Fd 2 error output (e.g. screen)
• On fork, child copies fd
• On exec, retains fd (except those specifically
  marked as close-on-exec fcntl(fd, F_SETFD,
  FD_CLOEXEC))

34
Case study the shell (cont.)

• I/O redirection ls gt tmp1
• How does the shell implement I/O redirection

fd open (tmp1, ) // error checking
omitted if (fd ! 1) dup2 (fd, 1) //
1 is a copy of fd, thus points to file tmp1
close (fd)
35

• System calls and API
• Q what system calls and APIs to provide?
• Q how to implement?
• Next OS design and implementation

36
OS design and implementation

• Design and Implementation of OS not solvable,
  but some approaches have proven successful
• Internal structure of different Operating Systems
  can vary widely
• Start by defining goals and specifications
• Affected by choice of hardware, type of system
• User goals and System goals
• User goals operating system should be
  convenient to use, easy to learn, reliable, safe,
  and fast
• System goals operating system should be easy to
  design, implement, and maintain, as well as
  flexible, reliable, error-free, and efficient

37
Operating System Design and Implementation (Cont.)

• Important principle to separate
• Policy What will be done? Mechanism How to
  do it?
• Mechanisms determine how to do something,
  policies decide what will be done
• The separation of policy from mechanism is a very
  important principle, it allows maximum
  flexibility if policy decisions are to be changed
  later

38
Simple Structure

• MS-DOS written to provide the most
  functionality in the least space
• Not divided into modules
• Although MS-DOS has some structure, its
  interfaces and levels of functionality are not
  well separated
• No protection ? user program crashes entire
  machine
• Hardware reason 8088 has no protection

39
MS-DOS Layer Structure
40
Unix

• UNIX limited by hardware functionality, the
  original UNIX operating system had limited
  structuring. The UNIX OS consists of two
  separable parts
• Systems programs
• The kernel
• Consists of everything below the system-call
  interface and above the physical hardware
• Provides the file system, CPU scheduling, memory
  management, and other operating-system functions
  a large number of functions for one level

41
UNIX System Structure
42
Layered Approach

• The operating system is divided into a number of
  layers (levels), each built on top of lower
  layers. The bottom layer (layer 0), is the
  hardware the highest (layer N) is the user
  interface.
• With modularity, layers are selected such that
  each uses functions (operations) and services of
  only lower-level layers

43
Layered Operating System
44
Microkernel System Structure

• Moves as much from the kernel into user space
• Communication takes place between user modules
  using message passing
• Claimed benefits
• Easier to extend a microkernel
• Easier to port the operating system to new
  architectures
• More reliable (less code is running in kernel
  mode)
• More secure
• Detriments
• Performance overhead of user space to kernel
  space communication

45
Mac OS X Structure
46
Modules

• Most modern operating systems implement kernel
  modules
• Uses object-oriented approach
• Function pointers in Linux OOP with C
• Each core component is separate
• Each talks to the others over known interfaces
• Each is loadable as needed within the kernel
• Overall, similar to layers but with more flexible

47
Solaris Modular Approach
48
Virtual Machines

• A virtual machine takes the layered approach to
  its logical conclusion. It treats hardware and
  the operating system kernel as though they were
  all hardware
• A virtual machine provides an interface identical
  to the underlying bare hardware
• The operating system creates the illusion of
  multiple processes, each executing on its own
  processor with its own (virtual) memory

49
Virtual Machines (Cont.)

• The resources of the physical computer are shared
  to create the virtual machines
• CPU scheduling can create the appearance that
  users have their own processor
• Spooling and a file system can provide virtual
  card readers and virtual line printers
• A normal user time-sharing terminal serves as the
  virtual machine operators console

50
Virtual Machines (Cont.)
Non-virtual Machine
Virtual Machine

• (a)

51
Virtual Machines (Cont.)

• The virtual-machine concept provides complete
  protection of system resources since each virtual
  machine is isolated from all other virtual
  machines. This isolation, however, permits no
  direct sharing of resources.
• A virtual-machine system is a perfect vehicle for
  operating-systems research and development.
  System development is done on the virtual
  machine, instead of on a physical machine and so
  does not disrupt normal system operation.
• The virtual machine concept is difficult to
  implement due to the effort required to provide
  an exact duplicate to the underlying machine

52
VMware Architecture
53
Next lecture

• Interrupts and system calls in Linux