From f6a5874daf238f079cc78efc0047e616c487e4b3 Mon Sep 17 00:00:00 2001 From: mo khan Date: Sun, 23 May 2021 13:38:11 -0600 Subject: finish notes on chapter 13. --- doc/13.md | 251 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 251 insertions(+) (limited to 'doc') diff --git a/doc/13.md b/doc/13.md index 139cae8..3f705de 100644 --- a/doc/13.md +++ b/doc/13.md @@ -67,3 +67,254 @@ A controller is a collection of electronics that can operate a port, a bus, or a | port | | port | ------------ ---------- ``` + +An I/O port consists of 4 registers: + +* data-in register: read by the host to get input. +* data-out register: written by the host to send output. +* status register: contains status/state bits to be read by the host. +* control register: can be written by the host to start a command or change device modes. + +Data registers are typically 1-4 bytes in size. + + +Host and controller protocol: + +1. host repeatedly reads the busy bit until it is clear. (polling) +1. host sets the write bit in the command register and writes a byte into the data-out register. +1. host sets the command-ready bit. +1. controller sees the command-ready bit set, it sets the busy bit. +1. controller reads the command register and sees the `write` command. + * it reads the `data-out` register to get the byte and does the I/O to the device. +1. controller clears the `command-ready` bit, clears the `error` bit in the status register to indicate the device I/O succeeded and clears the busy bit to indicate that it is finished. +1. loop + +```plaintext + + CPU + | (1) + ------------------------------- + |-->| device driver initiates I/O | + | ------------------------------- + | | + | CPU executing checks for + | transfers control to + | interrupt handler + | | + | V + | ---------------------------- ------------------------------ + | | CPU receiving interrupt, | | input ready, output | + | | transfers control to |<-----| complete, or error | + | | interrupt handler. | | generates interrupt signal | + | ---------------------------- ------------------------------ + | | + | V + | -------------------------- + | | interrupt handler | + | | processes data, | + | | returns from interrupt | + | -------------------------- + | | + | V + | ---------------------- + | | CPU resumes | + -----| processing of | + | interrupted task | + ---------------------- +``` + +## Interrupts + +The basic interrupt mechanism works as follows. + +* CPU hardware has a wire called the interrupt-request line +* CPU detects when a controller asserts a signal on the interrupt-request line +* CPU performs a state save and jumps to the interrupt-handler routine at a fixed address in memory. +* interrupt handler: + * determines cause of interrupt + * processes it + * performs a state restore + * executes a `return from interrupt` instruction to return the CPU to the execution state prior to the interrupt. + +Modern operating systems need more sophisticated interrupt-handling features. + +1. We need the ability to defer interrupt handling during critical processing. +1. We need an efficient way to dispatch to the proper interrupt handler for a device without first polling all devices to see which one raised the interrupt. +1. We need multilevel interrupts, so that the operating system can distinguish between high- and low-priority interrupts and can respond with the appropriate degree of urgency. + +CPUs have two interrupt request lines. + +1. nonmaskable interrupt: for events like unrecoverable memory errors. +1. maskable interrupt: used by device controllers to request a service. + + +address: number that selects a specific interrupt-handling routine. +interrupt vector: table that contains addresses for specific interrupt handlers. +interrupt chaining: used when more addresses are needed than available in the vector. +interrupt priority level: levels enable the CPU to defer the handling of low priority interrupts. + + +During boot the OS determines the hardware buses to detect devices then loads handlers into the interrupt vector for these devices. + +Example interrupt vector: + +| # | description | +|---|-------------| +| 0 | divide error | +| 1 | debug exception | +| 2 | null interrupt | +| 3 | breakpoint | +| 4 | INTO-detected overflow | +| ... | ... | +| 19-31 | Intel reserved, do not use | +| 32-255 | maskable interrupts | + +## Direct Memory Access + +Programmed I/O (PIO): processor to watch status bits and to feed data into a controller register one byte at a time. +Direct-memory access (DMA): operates on memory bus directly from start address to end address and frees CPU to do other things. + +DMA controller and device controller communicate via a pair of wires called DMA-request and DMA-acknowledge. + +## I/O Hardware Summary + +* bus +* controller +* i/o port and registers +* handshaking relationship between host and device controller +* execution of handshaking via polling or interrupts +* offloading of this work to a DMA controller for large transfers. + +## Application I/O Interface + +Abstraction, encapsulation and software layering. + +Standard set of functions defined by an `interface`. + +I/O subsystem is independent of the hardware simplifies the job of the OS developer. + +```plaintext + |----------------------------------------------------------------------------------------------------| + | | + | kernel | + | | + |----------------------------------------------------------------------------------------------------| + | kernel I/O subsystem | + |-------------|-----------------|--------------|-----|----------------|---------------|--------------| + | SCSI device | keyboard device | mouse device | ... | PCI bus device | floppy device | ATAPI device | + | driver | driver | driver | | driver | driver | driver | + ====================================================================================================== + | SCSI device | keyboard device | mouse device | ... | PCI bus device | floppy device | ATAPI device | + | controller | controller | controller | | controller | controller | controller | + |-------------|-----------------|--------------|-----|----------------|---------------|--------------| + A A A A A A A + | | | | | | | + V V V V V V V + |-----------| |---------------| |------------| |---| |--------------| |-------------| |-------------| + | SCSI | | keyboard | | mouse | | . | | PCI bus | | floppy disk | | ATAPI | + | devices | | | | | | | | | | drives | | devices | + |-----------| |---------------| |------------| |---| |--------------| |-------------| |-------------| +``` + + +Device driver interfaces differ for each operating system. + +* character-stream or block: transfers bytes one by one or a block of bytes as a unit. +* sequential or random access: transfer in fixed order or seek to any random location. +* synchronous or async: predictable reponse times or irregular or unpredictable reponse times. +* shared or dedicated: can be shared or used concurrently by several processes, thread or it cannot not. +* speek of operation: speeds range from a few bytes per second to few gigabytes per second. +* read-write, read only or write only: some devices perform both input and output, others do only operate in one direction. + +OS's can have an `escape` (or `back door`) that transparently passes arbitrary commands from an app to a device driver. +In UNIX, this system call is `ioctl()` for I/O control. This enables the application to access any functionality +that is available by a device driver, without the need to invent a new system call. + +```man +IOCTL(2) BSD System Calls Manual IOCTL(2) + +NAME + ioctl -- control device + +SYNOPSIS + #include + + int + ioctl(int fildes, unsigned long request, ...); + +DESCRIPTION + The ioctl() function manipulates the underlying device parameters of special files. In particular, many operating character- + istics of character special files (e.g. terminals) may be controlled with ioctl() requests. The argument fildes must be an + open file descriptor. + + An ioctl request has encoded in it whether the argument is an ``in'' parameter or ``out'' parameter, and the size of the + argument argp in bytes. Macros and defines used in specifying an ioctl request are located in the file . + +RETURN VALUES + If an error has occurred, a value of -1 is returned and errno is set to indicate the error. +``` + +The `block-device interface` captures aspects needed to access disks or other block devices. +Block devices can be accessed via `read()`, `write()` and `seek()`. + +A keyboard is accessed through a `character-stream interface`. The syscalls for this are `get()`, `put()`. +A socket interface is provided for network I/O via `select()`. + +Computers have hardware clocks and timers that provide: + +* give the current time +* give the elapsed time +* set a timer to trigger operation `X` at time `T`. + + +Blocking I/O vs. Non-blocking I/O. + +## Kernel I/O subsystem + +Kernel provides services related to I/O like: + +* scheduling +* bufferring +* caching +* spooling +* device reservation +* error handling + +Buffering is done for three reasons: + +* speed mismatch between producer and consumer +* provide adapters for devices that have different data-transfer sizes. +* support copy semantics for application I/O. + +A `cache` is a region of fast memory that holds copies of data. +A `spool` is a buffer that holds output for a device, such as a printer, that cannot accept interleaved data streams. + +The I/O subsystem supervises these procedures: + +* management of the name space for files and devices +* access control to files and devices +* operation control .e.g. `seek()` +* file-system space allocation +* device allocation +* buffering, caching and spooling +* I/O scheduling +* Device-status monitoring, error handling, and failure recovery +* Device-driver configuration and initialization. + +UNIX has a `mount table` that associates prefixes of path names with specific device names. +To resolve a path name, UNIX looks up the name in the mount table to find the longest matching prefix; +The corresponding entry in the mount table gives the device name. +The device name also has the form of a name in the file-system namespace. +When UNIX looks up this name it find a `` device number. +The major device number identifies the device driver that be called to handle I/O to this device. +The minor device number is passed to the device driver to index into a device table. +The corresponding device-table entry gives the port address or the memory-mapped address of the device controller. + +Improving I/O efficiency: + +* reduce the # of context switches +* reduce the # of times that data is copied in memory while passing between device and application. +* reduce the frequency of interrupts by using large transfers, smart controllers, and polling. +* increase concurrency by using DMA controllers or channels to offload simple data copying from the CPU. +* move processing primitives into hardware. +* balance CPU, memory, bus, and I/O performance. -- cgit v1.2.3