Commit f6a5874
Changed files (1)
doc
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 <sys/ioctl.h>
+
+ 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 <sys/ioctl.h>.
+
+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 `<major, minor>` 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.