INPUT/OUTPUT MANAGEMENT

1) The two main jobs of a computer are I/O and processing. In many cases, the main job
is I/O, and the processing is merely incidental.

2) For instance, when we browse a web page or edit a file, our immediate interest is to read
or enter some information, not to compute an answer.

3) The role of the operating system in computer I/O is to manage and control I/O operations
and I/O devices.

4) The nature of the hardware interface places constraints on the internal facilities of the
operating system.

5) The operating system bridges the gap between the hardware interface and the application
interface.

6) The performance aspects of I/O and the principles of operating-system design that
improve I/O performance.
7) The basic I/O hardware elements, such as ports, buses, and device controllers,
accommodate a wide variety of I/O devices.

What are input and output devices?

Input and output devices are components that form part of the computer system. These devices
are controlled by the operating system.

Input devices provide input signals such as commands to the operating system. These commands
received from input devices instruct the operating system to perform some task or control its
behavior.

Typical input devices are a keyboard, mouse, temperature sensor, air-flow valve or door switch.
In the previous example of our simple security control system, the input devices could be door
switches, alarm keypad panel and smoke detector units.

Output devices are instruments that receive commands or information from the operating
system.Typical output devices are monitor screens, printers, speakers, alarm bells, fans,
pumps, control valves, light bulbs and sirens.

CATEGORIES OF I/O DEVICES

• Human readable
– Used to communicate with the user
– Printers
– Video display terminals
• Display
• Keyboard
 • Mouse
• Machine readable
– Used to communicate with electronic equipment
– Disk and tape drives
– Sensors
– Controllers
– Actuators
• Communication
– Used to communicate with remote devices
– Digital line drivers
– Modems

DIFFERENCES IN I/O DEVICES

1. Data rate
May be differences of several orders of magnitude between the data transfer rates
2. Application

Disk used to store files requires file management software

Disk used to store virtual memory pages needs special hardware and software to support it
Terminal used by system administrator may have a higher priority
3. Complexity of control

4. Unit of transfer
Data may be transferred as a stream of bytes for a terminal or in larger blocks for a disk
5. Data representation
Encoding schemes
6. Error conditions
Devices respond to errors differently
8) To encapsulate the details and oddities of different devices, the kernel of an operating
system is structured to use device-driver modules. The device drivers present a uniform
device access interface to the I/O subsystem

9) I/O Components
1) I/O Hardware- physical equipment responsible for input and output operations.
It includes devices like keyboards, mice, printers, storage devices (hard drives,
SSDs), and network interfaces.
2) Application I/O Interface- the layer that applications interact with when
performing I/O operations. It provides high-level functions and methods for
applications to request and manage input and output
3) Kernel I/O Subsystem- The kernel is the core of the operating system, and the
I/O subsystem within the kernel manages communication between applications
and I/O devices. It includes device drivers, interrupt handlers. The kernel I/O
subsystem translates high-level commands from applications into low-level
commands that specific devices can understand
4) I/O Scheduling- I/O scheduling is a component within the kernel that manages
the order in which I/O requests are processed. It optimizes the sequence of
operations to improve efficiency and reduce wait times. it includes among others
Buffering, Caching, Spooling and Device Reservation, Error Handling, I/O
Protection, Kernel Data Structures

10) The device communicates with the machine via a connection point, or port—for
example, a serial port.

11) A bus is a set of wires and a rigidly defined protocol that specifies a set of messages that
can be sent on the wires.

12) A controller is a collection of electronics that can operate a port, a bus, or a device. A
serial-port controller is a simple device controller.

13) It is a single chip (or portion of a chip) in the computer that controls the signals on the
wires of a serial port.

14) By contrast, a SCSI bus controller is not simple. Because the SCSI protocol is complex,
the SCSI bus controller is often implemented as a separate circuit board (or a host
adapter) that plugs into the computer.

15) How can the processor give commands and data to a controller to accomplish an I/O
transfer? The short answer is that the controller has one or more registers for data and
control signals.
 16) An I/O port typically consists of four registers, called the status, control, data-in, and
data-out registers.
a. The host to get input reads the data-in register.
b. The data-out register is written by the host to send output.
c. The status register contains bits that can be read by the host. These bits indicate
states such as whether the current command has completed, whether a byte is
available to be read from the data-in register, and whether a device error has
occurred. It reflects the current state of affairs—whether the device connected to
the port is ready, busy, or has finished a task. It's a quick glance at what's going
on
d. The control register can be written by the host to start a command or to change
the mode of a device.

17) Interrupt; The basic interrupt mechanism works as follows. The CPU hardware has a
wire called the interrupt-request line that the CPU senses after executing every
instruction.

I/O DEVICE DRIVERS

1. In computing, a device driver or software driver is a computer program allowing

higher-levelcomputer programs to interact with a hardware device.
2. A driver typically communicates with the device through the computer bus or
communicationssubsystem to which the hardware connects.
3. When a calling program invokes a routine in the driver, the driver issues commands to
the device.
4. Once the device sends data back to the driver,the driver may invoke routines in the
original calling program.
5. Drivers are hardware-dependentand operating-system-specific. They usually provide
the interrupt handling required for any necessary asynchronous time-dependent
hardware interface.
6. A device driver simplifies programming by acting as translator between a hardware
device andthe applications or operating systems that use it.
7. Programmers can write the higher-level application code independently of whatever
specific hardware device.

Design

1. Device drivers can be abstracted into logical and physical layers.

2. Logical layers process data for a class of devices such as Ethernet ports or disk drives.
3. Physical layers communicate with specific device instances.

4. For example, a serial port needs to handle standard communication protocols such as
XON/XOFF that are common for all serial port hardware. This would be managed by a
serial port logical layer. However, the physical layer needs to communicate with a
particular serial port chip. 16550 UART hardware differs from PL-011.

The physical layer addresses these chip-specific variations. Conventionally, OS requests go to

 the logical layer first.In turn, the logical layer calls upon the physical layer to implement OS
requests in terms understandable by the hardware. Inversely, when a hardware device needs to
respond to the OS, it uses the physical layer to speak to the logical layer.

In Linux environments, programmers can build device drivers either as parts of the kernel or
separately as loadable modules. Makedev includes a list of the devices in Linux: ttyS (terminal),
lp (parallel port), hd (disk), loop (loopback disk device), sound (these include mixer, sequencer,
dsp, and audio).

The Microsoft Windows .sys files and Linux .ko modules contain loadable device drivers. The
advantage of loadable device drivers is that they can be loaded only when necessary and then
unloaded, thus saving kernel memory.

Development of drivers

1. Writing a device driver requires an in-depth understanding of how the hardware and the software
of a given platform function.
2. Drivers operate in a highly privileged environment and can cause disaster if they get things wrong.
3. In contrast, most user-level software on modern operating systems can be stopped without greatly
affecting the rest of the system. Even drivers executing in user mode can crash a system if the
device is erroneously programmed. These factors make it more difficult and dangerous to diagnose
problems.

4. Thus the task of writing drivers usually falls to software engineers who work for hardware-
development companies. This is because they have better information than most outsiders about
the design of their hardware.

5. Moreover, it was traditionally considered in the hardware manufacturer's interest to guarantee that
their clients can use their hardware in an optimum way.

6. Typically, the logical device driver (LDD) is written by the operating system vendor, while the
physical device driver (PDD) is implemented by the device vendor.

7. But in recent years non- vendors have written numerous device drivers, mainly for use with free
and open source operating systems. In such cases, it is important that the hardware manufacturer
provides information on how the device communicates. Although this information can instead be
learned by reverse engineering, this is much more difficult with hardware than it is with software.

8. Microsoft has attempted to reduce system instability due to poorly written device drivers by
creating a new framework for driver development, called Windows Driver Foundation (WDF).
This includes User-Mode Driver Framework (UMDF) that encourages development of certain
types of drivers — primarily those that implement a message-based protocol for communicating
with their devices — as user mode drivers. If such drivers malfunction, they do not cause system
instability. The Kernel-Mode Driver Framework (KMDF) model continues to allow development
of kernel-mode device drivers, but attempts to provide standard implementations of functions that
are well known to cause problems, including cancellation of I/O operations, power management,
and plug and play device support.

9. Apple has an open-source framework for developing drivers on Mac OS X called the I/O Kit.

Kernel-mode vs user-mode
 1. Device drivers, particularly on modern Windows platforms, can run in kernel-mode
(Ring 0) or in user-mode (Ring 3).
2. The primary benefit of running a driver in user mode is improved stability, since a
poorly written user mode device driver cannot crash the system by overwriting kernel
memory.
3. On the other hand, user/kernel-mode transitions usually impose a considerable
performance overhead, thereby prohibiting user mode-drivers for low latency and high
throughput requirements

Kernel space can be accessed by user module only through the use of system calls. End user
programs like the UNIX shell or other GUI based applications are part of the user space. These
applications interact with hardware through kernel supported functions.

Applications

Because of the diversity of modern hardware and operating systems, drivers operate in many
different environments. Drivers may interface with:

1) printers
2) video adapters
3) network cards
4) sound cards
5) local buses of various sorts — in particular, for bus mastering on modern systems
6) low-bandwidth I/O buses of various sorts (for pointing devices such as mice, keyboards,
USB, etc.)
7) computer storage devices such as hard disk, CD-ROM and floppy disk buses (ATA, SATA,
SCSI)
8) implementing support for different file systems
9) image scanners
10) digital cameras

Common levels of abstraction for device drivers include:

• for hardware:
o interfacing directly
o writing to or reading from a device control register
o using some higher-level interface (e.g. Video BIOS)
o using another lower-level device driver (e.g. file system drivers using disk
drivers)
o simulating work with hardware, while doing something entirely different
• for software:
o allowing the operating system direct access to hardware resources
o implementing only primitives
o implementing an interface for non-driver software (e.g. TWAIN)
o implementing a language, sometimes quite high-level (e.g. PostScript)

Choosing and installing the correct device drivers for given hardware is often a key
componentof computer system configuration.
 Virtual device drivers

1. Virtual device drivers represent a particular variant of device drivers. They are used to emulate a
hardware device, particularly in virtualization environments, for example when a DOS program is
run on a Microsoft Windows computer or when a guest operating system is run on, for example, a
Xen host.
2. These are software-based representations of hardware devices. Instead of controlling physical
hardware, virtual devices mimic the behavior of real devices within the software environment.
3. Instead of enabling the guest operating system to dialog with hardware, virtual device drivers take
the opposite role and emulate a piece of hardware, so that the guest operating system and its drivers
running inside a virtual machine can have the illusion of accessing real hardware.

4. Attempts by the guest operating system to access the hardware are routed to the virtual device driver
in the host operating system as e.g. function calls. The virtual device driver can also send simulated
processor-level events like interrupts into the virtual machine.

5. Virtual device drivers play a crucial role in virtualization technologies. They enable the creation and
management of virtual machines by providing the necessary interfaces for the virtualized operating
system to interact with emulated or simulated hardware

6. Virtual devices may also operate in a non-virtualized environment. For example a virtual network
adapter is used with a virtual private network, while a virtual disk device is used with iSCSI.

Open drivers
1. Typically refer to device drivers that are open-source. In the context of software and hardware,
"open-source" means that the source code of the software (in this case, the device driver) is freely
available for anyone to view, modify, and distribute.
2. Using open drivers adheres to the open-source software ideals of transparency, cooperation, and user
empowerment. It has the potential to contribute to a more inclusive and adaptable computer
environment
Examples of open drivers
• Printers: CUPS
• RAID arrays: CCISS[5]
• Scanners: SANE
• fas: Fast/wide SCSI controller
• hme: Fast (10/100 Mbit/s) Ethernet
• isp: Differential SCSI controllers and the SunSwift card
• glm: (Gigabaud Link Module[6]) UltraSCSI controllers
• scsi: Small Computer Serial Interface (SCSI) devices
• sf: soc+ or socal Fiber Channel Arbitrated Loop (FCAL)
• soc: SPARC Storage Array (SSA) controllers
• socal: Serial optical controllers for FCAL (soc+)

PRINCIPLES OF I/O SOFTWARE

As with any large software system, good design and layering is important.

GOALS OF THE I/O SOFTWARE

1. Device independence
 a) The concept of device independence refers to the ability of a system or application to
function and display content consistently across different types of devices,
b) The design of I/O software should prioritize independence from the particular
hardware components. This implies that application programs have the capability to
engage in input/output activities without requiring knowledge of the specific
intricacies associated with the underlying devices. Device drivers are of utmost
importance in attaining device independence.
c) The principle of device independence works very well with respect to random access
information storage devices. Essentially no level of software, from the OS upward
cares what kind of storage device it's reading from/ writing to.

d) It works fairly well in equating character input devices (e.g. keyboard) with disks and
character output devices (e.g. a character-oriented window) with disk; which is why
redirection can be done. For the most part, but with significant exceptions, software
that reads files from disk can be applied to take its input from the keyboard and vice
versa.

2. Uniform naming

e) The implementation of a standard interface serves to streamline the communication

between application programs and the input/output (I/O) subsystem. Irrespective of the
specific device employed, such as a disk, printer, or keyboard, it is imperative that a
uniform collection of operations or commands be accessible to application programs.
f) The implementation of a standardized interface across different devices guarantees
uniformity in input/output (I/O) processes. Application programs have the ability to
utilize a uniform set of commands or functions, irrespective of the underlying
hardware, hence facilitating simplicity and user-friendliness.
g) Recall that we discussed the value of the name space implemented by file systems.
There is no dependence between the name of the file and the device on which it is
stored. So a file called IAmStoredOnAHardDisk might well be stored on a floppy disk

3. Error handling
There are several aspects to error handling including: detection, correction (if possible) and
reporting.

a) Detection should be done as close to where the error occurred as possible before more
damage is done (fault containment). This is not trivial.

b) Correction is sometimes easy, for example ECC (error correcting code) memory does
this automatically (but the OS wants to know about the error so that it can schedule
replacement of the faulty chips before unrecoverable double errors occur).

c) Other easy cases include successful retries for failed ethernet transmissions. In this
example, while logging is appropriate, it is quite reasonable for no action to be taken.

d) Error reporting tends to be awful. The trouble is that the error occurs at a low level but
by the time it is reported the context is lost. Unix/Linux in particular is horrible in this
area.
4. Creating the illusion of synchronous I/O

a) I/O must be asynchronous for good performance. That is the OS cannot simply wait
for an I/O to complete. Instead, it proceeds with other activities and responds to the
notification when the I/O has finished.

b) I/O software should support asynchronous operations, allowing programs to continue

executing while waiting for I/O to complete. This principle enhances system
responsiveness and efficiency

5. Buffering

Buffering involves temporarily storing data in memory before or after I/O operations.
This principle helps in smoothing out variations in data transfer rates between devices,
improving overall system performance.

I/O SOFTWARE LAYERS (Layers of Abstraction)

Layers of abstraction as usual prove to be effective. Most systems are believed to use
the following layers (but for many systems, the OS code is not available for
inspection).

1. User level I/O routines.

2. Device independent I/O software.
3. Device drivers.
4. Interrupt handlers.

1. User Level I/O Routines:

layer closest to the application. It includes high-level I/O functions that applications use to
interact with devices without getting into the nitty-gritty details e. g printf or fwrite in C,
which allow applications to write data without worrying about the specifics of the
underlying devices.

2. Device independent I/O software.

bridge between the high-level user routines and the specifics of individual devices. It
abstracts away device details, making I/O operations independent of the particular
hardware.
e.g. Libraries or functions that handle generic I/O operations, translating them into
device-specific commands.

3. Device drivers.
interacts directly with the hardware. They provide a standardized interface for the
operating system and user-level software to communicate with specific devices.
e.g. A driver for a printer would handle the translation of generic print commands into
signals the printer understands.

4. Interrupt handlers.
When a device has completed an operation or requires attention, it signals the CPU
through interrupts. Interrupt handlers are responsible for managing these signals and
ensuring the appropriate response.
e.g. When a disk operation is complete, the disk controller sends an interrupt, and the
interrupt handler takes over to inform the operating system.