[WARNINGS] link-id not found - [fmiosacomparativestudypartikernellandchapter1bootup|1 link-id not found - [fmiosacomparativestudypartikernellandchapter3scheduling|3 link-id not found - [fmiosacomparativestudypartikernellandchapter5memorymanagement|5 link-id not found - [fmiosacomparativestudypartikernellandchapter7deadlocks|7 link-id not found - [fmiosacomparativestudypartiiuserlandchapter8iolayers|8 link-id not found - [fmiosacomparativestudypartiiuserlandchapter10environmentlayer|10
Intro (I 1 2 3 4 5 6 7) (II 8 9 10 11) (D) (C) (B
I)
h1. Chapter 8: I/O Layers
To take the discussion into User Space, an overview of the layering of system resources used in Input/Output will be made. Data flows through these layers as they make their way from the devices to the user, and vice versa. This will help set the stage for the chapters on file systems, environment layer, and security.
h2. Layer 1: Device
This is the bottom-most layer consisting of the hardware device itself. Devices come in two basic flavors.
Block devices do their reading and writing in blocks, such as on a disk.
Character devices read and write as a stream of characters, such as on a network adapter or keyboard.
h2. Layer 2: Device Controller
The device is electronically controlled by a device controller. The controller is typically built into the hardware of the device and has its own registers and data buffer used when dealing with the device. Controllers are programmable devices, their control language being specific to the device itself. The control commands may be standardized but often will differ according to the device manufacturer.
h2. Layer 3: Kernel Control
The controllers are assigned I/O ports (for the IPC) or are often memory-mapped by the memory manager. E.g. data may be written to the device by "pretending" to write to ram at specified addresses (Section 56).
This layer is also where the kernel starts stepping in. One of the basic jobs of the kernel is to provide a layer of abstraction from the hardware to the software. It must also make sure that this layer is as device-independent as possible, for the sake of the users and of portability. This requires a method of uniform naming for these I/O ports, and uniform access. The kernel must also determine whether it implements synchronous access (where it blocks requesting threads while it's handling their request) or asynchronous access (where it allows the requesting thread to continue to run and notifying it, by way of interrupts, that the request is done).
This is also the layer in which the OS may implement any buffer caching.
There are different methods in which the kernel can deal with sending information to the I/O device:
Programmed I/O. In this method the kernel sends data to the I/O device one buffer at a time. To do this it must busy-wait while polling the device to see if it's ready for the next datum, much like a spinlock would do. Also, like a spinlock, processor time is consumed in a waiting loop.
Interrupts. If using this method, the kernel copies the data from the user to some temporary buffer. It then blocks the requesting thread and schedules as normal, leaving the device interrupt handler to copy the buffer, byte-by-byte.
DMA. This method is the same as using interrupts except that the kernel hands the buffer address to a DMA controller and gets only ONE interrupt from the DMA saying it's done sending the buffer, in full, to the device. DMA stands for Direct Memory Access and is a hardware layer between the device and the kernel that is sometimes part of the device controller or the CPU.
The kernel then provides a uniform standard for writing to the I/O, using such straightforward calls as @read()@ and @write()@ or redirections, such as @<@ and @>@, that are commonly used in POSIX environments.
h2. Layer 4: Device Driver
This layer consists of the device driver software. The driver is specific to the device (device-dependent) and knows how best to use the OS's access to the device, in accordance to the distinct device.
h3. Monolithic kernels
Since the drivers are in the kernel, the kernel must be recompiled to include any new device if one is added to the machine (some monolithic OSes have a modular device plugging system, like Linux). This, however, leaves the kernel vulnerable to faulty drivers. If a driver was to crash or misbehave, the entire kernel could shut down, leaving the computer incapacitated or worse, damage permanent data files.
h3. Microkernel and Client-Server models
With the drivers in user space, driver code is isolated from the kernel. Therefore, if drivers misbehave, will do so in their own space and not take the kernel with it. These user space drivers get their device access via syscalls and IPC.
Although these drivers are obviously device-dependent, their exported API must be device-independent and meet a certain functionality standard (i.e. Win32 or POSIX) for the next layer to use.
h2. Layer 5: Device-Independent software
This layer bundles different I/O calls together into uniform/standard interfaces for programs to use. For example, writing to the printer is a similar interface as writing to disk and as writing to a network interface. This layer also takes care of uniform naming, protections, blocking (if the kernel doesn't automatically do it), buffering, allocation/releasing, error reporting, etc.
h2. Layer 6: User-level software
This is the final (topmost) layer where all device access is now uniform and abstracted. Users can program using system calls, or useful libraries that bundle different calls together for improved functionality. Functions such as @read()@, @write()@, @open()@, etc., are part of this layer.
Now, with this generalized look at the I/O layers of a typical machine, we move on to File Systems.
(c)2006 Dimitri Hammond