Please enable JavaScript.

Coggle requires JavaScript to display documents.

Devices For a system to be really useful, we need to be able to…

- - - - High-level Abstract Primitives
        The interface between application and device driver
        
        open()/close()
        Setup device for start and termination of I/O
        
        getc()/putc()
        Single character transfers
        
        read()/write()
        Block transfers (disk, drivers)
        
        ioctl()
        Way to pass special control information
        
        Required because not all operations fit inside the I/O model
        
        For performing non I/O operations on the device
        
        Different numbers and types of parameters
        
        First parameter is file descriptor
        
        Second parameter is specific ioctl request identifier
        
        e.g. ioctl(d, DEV_BUFFER_CONFIG, 65536, ASYNC)
        
        seek()
        Special case of control to position a device for data transfer
        
        inputintr()
        Input-arrived interrupt
        
        outputintr()
        Output-finished interrupt
        
        init()
        Called to setup device
      - Standard Design
        
        Device Interface
        
        Common to all devices
        
        What the application seed
        
        Device Driver
        
        One per device
        
        Upper Half
        
        Maps application requests to hardware
        
        High level device management
        
        Lower Half
        
        Device hardware manipulation
        
        Translates upper half requests to hardware commands
        
        Services hardware interrupts
        
        User request queues to communicate between upper and lower half of device driver
        
        Device Categories
        
        Physical Devices
        
        Correspond to physical hardware
        
        Require a lower half
        
        e.g. hard disk, audio device
        
        Virtual Devices
        
        Does not correspond to hardware
        
        Does not require lower half
        
        e.g. /dev/null, dev/zero, sockets
        
        Character Devices
        
        Send and receive 1 character at a time
        
        Usually cannot seek
        
        Think of as data stream
        
        e.g. printers, audio device, scanner, kerboard
        
        Block Devices
        
        Reads/writes in fixed block sizes
        
        Usually supports random access (seek)
        
        Generally abstraction takes care of difference between character and block devices
      - Device Table
        
        Device Structure
        
        Pointers to functions to perform various services
        
        Basic device identification data
        
        Data required to access device
        
        Pointer to data used by this device's functions
        
        Device Number
        
        Major: type of device
        
        Minor: instance of device type
        
        Each entry is a device structure
        
        Each entry corresponds to a device
      - Device Naming
        
        File System
        
        Devices are special files within the file system
        
        Device name in the form /dev/<device>
        
        Provides uniformity of access
        
        Applications treat devices as files
        
        File system and device interface merged
        
        Not good for non-I/O devices
        
        Device Registry
        
        Keep separate registry of devices
        
        System calls to access the registry
        
        Supports greater variety of devices
      - Device Binding
        
        File System Approach
        
        File is created with special characteristics
        
        Two-number identification
        
        Major: device type
        
        Minor: identifies subunit of that device
        
        Device Registry Approach
        
        Registry contains identifiers denoting device type and instance
        
        Can be thought of as major/minor device numbers
        
        Identifier to Driver Mapping
        
        Kernel keeps a device block table
        
        Index this table by major/minor number
        
        Table is set up at compile/initialize time
- - - - Device major & minor numbers
      - Pointer to device in device block table
      - Pointer to device control data
      - Device name and status
  - - - Operation blocks process until devices has completed processing the request
      - Once system call returns, caller is guaranteed operation has completed or failed
      - e.g. read(), open(), putc()
    - - No guarantee operation completed when caller returns
      - Device processing and caller processing can overlap
      - Caller needs to check if operation complete
        aiowrite(), aioread()
      - Checking may be difficult or impossible on some systems
      - Caller may be blocked if there are no empty buffers
    - - Operations on Device Driver State
        
        e.g. open(), close(), ioctl()
        
        Operations not dependent on the device being available immediately
      - Operations on the Actual Device
        
        e.g. read(), write(), sometimes ioctl()
        
        Requires communication with the lower half
  - - - If notified of work, examine queues and perform request
      - An interrupt should go off signifying device has completed work
      - ISR invoked to complete the request
        
        Determine which request completed
        
        Notify upper half using function call
        
        Finish request (i.e. send data back or something)
        
        Place blocked process on ready queue
  - - - Occurs when all buffers are used. Free results are used immediately and cause high context switching overhead
      - Solve by using a watermark
        
        On write, don't send util a certain number of buffers are ready
        
        on read, don't restart device until watermark is reached
        
        Watermark produces a buffering effect
  - - - Device-dependent open()
        
        Device-specific initialization
        
        Allocate per-process device block
        
        Allocate device descriptor
        
        Device block
        
        Device-independent state
        
        Index device block into PCB's device table
        
        Configure Device
        
        Using ioctl()
        
        Either
        
        Create control requests for processing by lower half; or
        
        Make direct calls to lower half to control device
        
        Return to dispatcher
        
        Write to Device
        
        Device independent write() calls device-dependent write()
        
        Creates request and copies data into buffer if available
        
        Enqueue request
        
        If device is idle, lower half is notified
        
        If data cannot be processed, request placed on blocked queue
        
        Write Request Completes
        
        Enter kernel via CS
        
        Dispatcher calls lower half of device driver (ISR)
        
        Lower half notifies upper half request is complete
        
        Upper half moves requesting process to ready queue
        
        Return to dispatcher
- - - - Prevents having to iterate the whole queue to decrement counters
- - - - Can be read or written
      - Typically indicate some sort of device status
      - Writing to these registers acknowledges some sort of condition
    - - Written to tell the hardware what to do or to provide data
    - - Read to get data
  - - - Only works for internal devices
    - - Keep checking until device indicates it isn't busy
      - Poll occasionally
    - - Used by most devices
      - Causes CS (expensive)
      - Minimizes wait before device served
      - CPU freed to perform other tasks
  - - - Advantage: no special CPU instructions
      - Disadvantage: makes physical memory discontiguous
      - Device registers are mapped to memory addresses
      - To read/write from/to registers, just read/write from/to those addresses
    - - Ports are separate address spaces
      - Just like "normal" address spaces, ports are identified by addresses
      - Registers of device are mapped/connected to particular port addresses
      - Special instruction in is used to read from ports
      - Special instruction out is used to write to port addresses
      - Advantage: does not create discontinuity in physical addresses
      - Disadvantage: in/out operations are relatively slow an limited in data size
    - - Used with character devices
      - CPU reads/writes one word to/from device at a time
      - Uses in/out instructions
      - CPU waits
      - Amount of data per call is small
      - Not good for block devices
      - Data routes
        
        Memory->CPU->Device
        
        Device->CPU->Memory
    - - DMA Engine
        
        Bidirectional data transfer between device and memory
        
        CPU specifies memory location to device
        
        Device uses DMA engine to transfer data
        
        Device interrupts CPU once transfer completes
      - DMA engine shares memory bus with CPU (steals cycles)
        
        Reduces # of memory operations CPU can perform
        
        Devices are slow, so stealing is small
        
        CPU can do other things during DMA