IO Devices and Drivers

1
I/O Devices and Drivers

• Vivek Pai / Kai Li
• Princeton University

2
Mechanics

• Project extension 2 days
• Project 5/6 schedule may change
• Design review sign-ups on door
• Reading - 4.0, 4.1, 4.3, 4.6.3
• Quiz 4 returned
• Exams taking longer than expected
• Goal end of this week

3
Mechanics - Grades

• Quiz 1
• 0 1
• 0.5 2
• 1.0 4
• 1.5 2
• 2.0 11
• 2.5 12
• 3.0 9
• 3.5 5
• 4.0 - 12

• Quiz 2
• 1.5 1
• 2.0 3
• 2.5 6
• 3.0 30
• 3.5 4
• 4.0 14

4
Mechanics - Grades

• Quiz 3
• 1.0 1
• 2.0 4
• 2.5 3
• 3.0 13
• 3.5 8
• 4.0 - 29

• Quiz 4
• 0 12
• 0.5 4
• 1.0 4
• 1.5 2
• 2.0 6
• 2.5 6
• 3.0 10
• 3.5 5
• 4.0 9

5
Quiz 4 Answers

• Deadlock and its symptoms
• Circular wait, no progress
• Which condition isnt necessary
• Priority scheme
• Bakers algorithm
• Not safe 2 avail, 3 possibly required
• AcquireLockIfAvailable
• If not acquired, release all, try again

6
Overview

• Data must enter/leave the system
• How do we communicate with devices?
• How does data get transferred?
• How do we structure the OS?
• How do we increase flexibility?

7
Definitions General Method

• Overhead
• CPU time to initiate operation (cannot be
  overlapped)
• Latency
• Time to perform 1-byte I/O operation
• Bandwidth
• Rate of I/O transfer, once initiated
• General method
• Abstraction of byte transfers
• Batch transfers into block I/O for efficiency to
  prorate overhead and latency over a large unit

8
Overview

• Data must enter/leave the system
• How do we communicate with devices?
• Special instructions (in/out port/device)
• Memory-mapped logic on adaptor
• How does data get transferred?
• How do we structure the OS?
• How do we increase flexibility?

9
Overview

• Data must enter/leave the system
• How do we communicate with devices?
• How does data get transferred?
• Each byte moved manually handshaking
• Separate engine arranges movement
• How do we structure the OS?
• How do we increase flexibility?

10
Programmed I/O Slow Input Device
CPU

• Device
• Data registers
• Status register(ready, busy, interrupt, )
• A simple mouse design
• Put (X, Y) in data registers on a move
• Interrupt
• Perform an input
• On an interrupt
• reads values in X, Y registers
• sets ready bit
• wakes up a process/thread or execute a piece of
  code

Memory
L2 Cache
I/O Bus
Interface
X
Y
11
Programmed I/O Output Device

• Device
• Data registers
• Status registers (ready, busy, )
• Perform an output
• Polls the busy bit
• Writes the data to data register(s)
• Sets ready bit
• Controller sets busy bit and transfers data
• Controller clears the ready bit and busy bit

12
Direct Memory Access (DMA)
Free to move data during DMA

• Perform DMA from host CPU
• Device driver call (kernel mode)
• Wait until DMA device is free
• Initiate a DMA transaction(command, memory
  address, size)
• Block
• DMA interface
• DMA data to device(size-- address)
• Interrupt on completion(size 0)
• Interrupt handler (on completion)
• Wakeup the blocked process

CPU
Memory
L2 Cache
I/O Bus
DMA Interface
13
Overview

• Data must enter/leave the system
• How do we communicate with devices?
• How does data get transferred?
• How do we structure the OS?
• Standard interface between OS/device
• Moves intimate knowledge out of OS
• How do we increase flexibility?

14
Device Drivers
I/O System
Rest of the operating system
Device driver
Device controller
Device
Device driver
Device controller
Device
. . .
. . .
Device
Device driver
Device controller
Device
15
Device Driver Design Issues

• Operating system and driver communication
• Commands and data between OS and device drivers
• Driver and hardware communication
• Commands and data between driver and hardware
• Driver operations
• Initialize devices
• Interpreting commands from OS
• Schedule multiple outstanding requests
• Manage data transfers
• Accept and process interrupts
• Maintain the integrity of driver and kernel data
  structures

16
Device Driver Interface

• Open( deviceNumber )
• Initialization and allocate resources (buffers)
• Close( deviceNumber )
• Cleanup, deallocate, and possibly turnoff
• Device driver types
• Block fixed sized block data transfer
• Character variable sized data transfer
• Terminal character driver with terminal control
• Network streams for networking

17
Block Device Interface

• read( deviceNumber, deviceAddr, bufferAddr )
• transfer a block of data from deviceAddr to
  bufferAddr
• write( deviceNumber, deviceAddr, bufferAddr )
• transfer a block of data from bufferAddr to
  deviceAddr
• seek( deviceNumber, deviceAddress )
• move the head to the correct position
• usually not necessary

18
Character Device Interface

• read( deviceNumber, bufferAddr, size )
• reads size bytes from a byte stream device to
  bufferAddr
• write( deviceNumber, bufferAddr, size )
• write size bytes from bufferSize to a byte
  stream device

19
Unix Device Driver Interface Entry Points

• init() Initialize hardware
• start() Boot time initialization (require system
  services)
• open(dev, flag, id) initialization for read or
  write
• close(dev, flag, id) release resources after
  read and write
• halt() call before the system is shutdown
• intr(vector) called by the kernel on a hardware
  interrupt
• read/write calls data transfer
• poll(pri) called by the kernel 25 to 100 times a
  second
• ioctl(dev, cmd, arg, mode) special request
  processing

20
Overview

• Data must enter/leave the system
• How do we communicate with devices?
• How does data get transferred?
• How do we structure the OS?
• How do we increase flexibility?
• Sync/Async I/O, buffering in kernel
• Dynamic loading/binding

21
Why Buffering

• Speed mismatch between producer and consumer
• Character device and block device, for example
• Adapt different data transfer sizes
• Packets vs. streams
• Support copy semantics
• Deal with address translation
• I/O devices see physical memory, but programs use
  virtual memory
• Spooling
• Avoid deadlock problems
• Caching
• Avoid I/O operations

22
Detailed Steps of Blocked Read

• A process issues a read call which executes a
  system call
• System call code checks for correctness and cache
• If it needs to perform I/O, it will issues a
  device driver call
• Device driver allocates a buffer for read and
  schedules I/O
• Controller performs DMA data transfer, blocks the
  process
• Device generates an interrupt on completion
• Interrupt handler stores any data and notifies
  completion
• Move data from kernel buffer to user buffer and
  wakeup blocked process
• User process continues

23
Asynchronous I/O

• Why do we want asynchronous I/O?
• Life is simple if all I/O is synchronous
• How to implement asynchronous I/O?
• On a read
• copy data from a system buffer if the data is
  thereOtherwise, initiate I/O
• How does process find out about completion?
• On a write
• copy to a system buffer, initiate the write and
  return

24
Other Design Issues

• Build device drivers
• statically
• dynamically
• How to down load device driver dynamically?
• load drivers into kernel memory
• install entry points and maintain related data
  structures
• initialize the device drivers

25
Dynamic Binding with An Indirect Table
Open( 1, )
Indirect table
Driver for device 0
open()
Driver-kernel interface
read()
Interrupt handlers
Driver for device 1
open()
Other Kernel services
read()
26
Dynamic Binding

• Download drivers by users (may require a reboot)
• Allocate a piece of kernel memory
• Put device driver into the memory
• Bind device driver with the device
• Pros flexible and support ISVs and IHVs
• Cons security holes

27
Think About Performance

• A terminal connects to computer via a serial line
• Type character and get characters back to display
• RS-232 is bit serial start bit, character code,
  stop bit (9600 baud)
• Do we have any cycles left?
• 10 users or 10 modems
• 900 interrupts/sec per user
• Overhead of handing an interrupt 100 msec