I/O Systems: Overview, Application I/O Interface, Kernel I/O Subsystem,

Transforming I/O Requests to Hardware Operations.

I/O Systems:
Overview

The control of devices connected to the computer is a major concern of

operating-system designers. Because I/O devices vary so widely in their
function and speed (consider a mouse, a hard disk, and a tape robot), varied
methods are needed to control them. These methods form the I/O subsystem of
the kernel, which separates the rest of the kernel from the complexities of
managing I/O devices.

Application IO Interface

An IO (Input/output) Interface is a mechanism through which a computer or a

device communicates with the outside world. It allows the exchange of data
between the system and external devices such as keyboards, mice, printers, or
network adapters. The IO Interface acts as a bridge, facilitating the transfer of
information in a standardized manner.

Types of IO Interfaces

There are several types of IO Interfaces, each tailored to meet specific

requirements. Some common types include:

 Serial Interface
 Parallel Interface
 USB Interface
 Ethernet Interface

Implementing IO Interface

Step 1: Identify Your Requirements

Before implementing an IO Interface, it is crucial to identify your specific

requirements. Consider the devices you want to connect, the data transfer speed,
and compatibility with your existing system. This will help you choose the right
type of IO Interface for your application.

Step 2: Select the Appropriate IO Interface

Once you have identified your requirements, select the IO Interface that best suits
your needs. Conduct thorough research, compare different options, and analyze
their pros and cons. Ensure compatibility with your hardware and software
components.
Step 3: Connect the External Device

Now, it’s time to physically connect the external device to your system.
Depending on the type of IO Interface, you may need to use specific cables,
connectors, or adapters.

Step 4: Install Required Drivers

In order for your system to recognize and communicate with the external device,
you may need to install the required drivers. These drivers act as intermediaries,
enabling the IO Interface to interact with the device.

Step 5: Configure the IO Interface

Once the drivers are installed, you may need to configure the IO Interface
settings. This involves specifying parameters such as data transfer mode, baud
rate, or network configuration.

Advantages of IO Interface

The IO Interface offers several advantages, including:

 Streamlined Communication: With an IO Interface, your application can

seamlessly communicate with external devices, enabling efficient data
transfer.
 Standardization: IO Interfaces follow industry standards, ensuring
compatibility across different systems and devices.
 Expandability: IO Interfaces provide the flexibility to connect multiple
devices, expanding the capabilities of your application.
 Improved Performance: By offloading input/output tasks to dedicated
interfaces, your system’s overall performance can be enhanced.

Kernel IO Subsystem
Kernels provide many services related to I/O. Several services like
scheduling, buffering, caching, spooling, device reservation, and error
handling are provided by the kernel’s I/O subsystem and build on the
hardware and device-driver infrastructure. The I/O subsystem is also
responsible for protecting itself from errant (problematic) processes and
malicious users.

I/O Scheduling
To schedule a set of I/O requests means to determine a good order in
which to execute them. The order in which applications issue system calls
rarely is the best choice. Scheduling can improve overall system
 performance, can share device access fairly among processes, and can
reduce the average waiting time for I/O to complete.

Buffering
A buffer, of course, is a memory area that stores data being transferred
between two devices or between a device and an application. Buffering is
done for three reasons.
One reason is to cope with a speed mismatch between the producer and
consumer of a data stream.

A second use of buffering is to provide adaptations for devices that have

different data-transfer sizes. Such disparities are especially common in
computer networking, where buffers are used widely for fragmentation
and reassembly of messages. At the sending side, a large message is
fragmented into small network packets. The packets are sent over the
network, and the receiving side places them in a reassembly buffer to form
an image of the source data.

A third use of buffering is to support copy semantics for application I/O.

With copy semantics, the version of the data written to disk is guaranteed
to be the version at the time of the application system call, independent of
any subsequent changes in the application’s buffer.

Caching
A cache is a region of fast memory that holds copies of data. Access to the
cached copy is more efficient than access to the original. For instance, the
instructions of the currently running process are stored on disk, cached in
physical memory, and copied again in the CPU’s secondary and primary
caches. The difference between a buffer and a cache is that a buffer may
hold the only existing copy of a data item, whereas a cache, by definition,
holds a copy on faster storage of an item that resides elsewhere.

Spooling
A spool is a buffer that holds output for a device, such as a printer, that
cannot accept interleaved data streams. Although a printer can serve only
one job at a time, several applications may wish to print their output
concurrently, without having their output mixed together. The operating
system solves this problem by intercepting all output to the printer. Each
application’s output is spooled to a separate disk file. When an application
finishes printing, the spooling system queues the corresponding spool file
for output to the printer.

Error Handling
An operating system that uses protected memory can guard against many
kinds of hardware and application errors, so that a complete system failure
is not the usual result of each minor mechanical malfunction.
Transforming I/O Requests to Hardware Operations.
We know that there is handshaking between device driver and device
controller but here question is that how operating system connects
application request or we can say I/O request to set of network wires or to
specific disk sector or we can say to hardware -operations.

The question is how the operating system connects an application request

to a set of network wires or to a specific disk sector. Consider, for
example, reading a file from disk. Within a disk, the file system maps
from the file name through the file-system directories to obtain the space
allocation of the file.

One method is that used by MS-DOS, a relatively simple operating

system. The first part of an MS-DOS file name, preceding the colon, is a
string that identifies a specific hardware device. For example, C: is the
first part of every file name on the primary hard disk. The fact that C:
represents the primary hard disk is built into the operating system; C: is
mapped to a specific port address through a device table. Because of the
colon separator, the device name space is separate from the file-system
name space. This separation makes it easy for the operating system to
associate extra functionality with each device.

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.
 user I/O completed, input
request I/O process data available, or
output completed

system call
return from system call

kernel
I/O subsystem transfer data
can already (if appropriate) to process,
satisfy request? yes return completion
or error code
no

send request to device

driver, block process if kernel
appropriate I/O subsystem

process request, issue

commands to controller, device determine which I/O
configure controller to driver completed, indicate state
block until interrupted change to I/O subsystem

interrupt receive interrupt, store

device-controller commands handler data in device-driver
buffer if input, signal to
unblock device driver

interrupt

device
monitor device, controller interrupt when I/O
I/O completed,
generate interrupt

completed

time

Figure 13.13 The life cycle of an I/O request.

The typical life cycle of a blocking read request, as depicted in Figure 13.13.
The figure suggests that an I/O operation requires a great many steps that together
consume a tremendous number of CPU cycles.

1. A process issues a blocking read() system call to a file descriptor of a file that
has been opened previously.
2. The system-call code in the kernel checks the parameters for correctness. In the
case of input, if the data are already available in the buffer cache, the data are
returned to the process, and the I/O request is completed.
 3. Otherwise, a physical I/O must be performed. The process is removed from the run queue and is
placed on the wait queue for the device, and the I/O request is scheduled. Then, the I/O subsystem
sends the request to the device driver.

4. The device driver allocates kernel buffer space to receive the data and schedules the I/O.
Eventually, the driver sends commands to the device controller by writing into the device-
control registers.
5. The device controller operates the device hardware to perform the data transfer.
6. The driver may poll for status and data, or it may have set up a DMA transfer into kernel
memory.

7. The correct interrupt handler receives the interrupt via the interrupt-vector table, stores any
necessary data, signals the device driver, and returns from the interrupt.
8. The device driver receives the signal, determines which I/O request has completed, determines
the request’s status, and signals the kernel I/O subsystem that the request has been completed.
9. The kernel transfers data or return codes to the address space of the requesting process and
moves the process from the wait queue back to the ready queue.

10. Moving the process to the ready queue unblocks the process. When the scheduler assigns the
process to the CPU, the process resumes execution at the completion of the system call.