MODULE 3

INPUT/OUTPUT SYSTEM ARCHITECTURE

The computer system’s I/O architecture is its interface to the outside world. This architecture is
designed to provide a systematic means of controlling interaction with the outside world and to
provide the operating system with the information it needs to manage I/O activity effectively.
The basic idea is to select a mode of communication taking device characteristics into account or
a need to synchronize with some event, or to just have a simple strategy to ensure a reliable
assured IO.
Computers employ the following four basic modes of IO operation:
1. Programmed mode
2. Polling mode
3. Interrupt mode
4. Direct memory access mode.
We shall discuss each of these modes in some detail now.
1. Programmed Data Mode
In this mode of communication, execution of an IO instruction ensures that a program shall not
advance till it is completed. To that extent one is assured that IO happens before anything else
happens. As depicted in Figure 3.1, in this mode an IO instruction is issued to an IO device and
the program executes in “busy-waiting” (idling) mode till the IO is completed. During the busy-
wait period the processor is continually interrogating to check if the device has completed IO.
Invariably the data transfer is accomplished through an identified register and a flag in a
processor. For example, in Figure 3.1 depicts how an input can happen using the programmed
data mode. First the processor issues an IO request (shown as 1), followed by device putting a
data in a register (shown as 2) and finally the flag (which is being interrogated) is set (shown as
3). The device either puts a data in the register (as in case of input) or it picks up data from the
register (in case of output). When the IO is accomplished it signals the processor through the
flag. During the busy-wait period the processor is busy checking the flag. However, the
processor is idling from the point of view of doing anything useful. This situation is similar to a
car engine which is running when the car is not in motion – essentially “idling”.

Figure 3.1: Programmed mode of IO.

 2. Polling
In this mode of data transfer, shown in Figure 3.2, the system interrogates each device in turn to
determine if it is ready to communicate. If it is ready, communication is initiated and
subsequently the process continues again to interrogate in the same sequence. This is just like a
round-robin strategy. Each IO device gets an opportunity to establish Communication in turn. No
device has a particular advantage (like say a priority) over other devices.
Polling is quite commonly used by systems to interrogate ports on a network. Polling
may also be scheduled to interrogate at some pre-assigned time intervals. It should be remarked
here that most daemon software operate in polling mode. Essentially, they use a while true loop
as shown in Figure 3.2.
In hardware, this may typically translate to the following protocol:
1. Assign a distinct address to each device connected to a bus.
2. The bus controller scans through the addresses in sequence to find which device wishes to
establish a communication.
3. Allow the device that is ready to communicate to leave its data on the register.
4. The IO is accomplished. In case of an input the processor picks up the data. In case of an
output the device picks up the data.
5. Move to interrogate the next device address in sequence to check if it is ready to
communicate.

Figure 3.2: Polling mode of IO.

3. Interrupt Mode
Let us begin with a simple illustration to explain the basic rationale behind interrupt
mode of data transfer. Suppose a program needs input from a device which communicates using
interrupt. Even with the present-day technology the devices are one thousand or more times
slower than the processor. So if the program waits on the input device it would cycle through
many processor cycles just waiting for the input device to be ready to communicate. This is
where the interrupt mode of communication scores.
To begin with, a program may initiate IO request and advance without suspending its operation.
At the time when the device is actually ready to establish an IO, the device raises an interrupt to
seek communication. Immediately the program execution is suspended temporarily and current
state of the process is stored. The control is passed on to an interrupt service routine (which may
be specific to the device) to perform the desired input. Subsequently, the suspended process
context is restored to resume the program from the point of its suspension.
Interrupt processing may happen in the following contexts:
  Internal Interrupt: The source of interrupt may be a memory resident process or a
function from within the processor. We regard such an interrupt as an internal interrupt.
A processor malfunction results in an internal interrupt. An attempt to divide by zero or
execute an illegal or non-existent instruction code results in an internal interrupt as well.
A malfunction arising from a division by zero is called a trap. Internal interrupt may be
caused by a timer as well. This may be because either the allocated processor time slice
to a process has elapsed or for some
reason the process needs to be pre-empted. Note that an RTOS may pre-empt a running process
by using an interrupt to ensure that the stipulated response time required is met. This would also
be a case of internal interrupt.
 External Interrupt: If the source of interrupt in not internal, i.e. it is other than a process
or processor related event then it is an external interrupt. This may be caused by a device
which is seeking attention of a processor. As indicated earlier, a program may seek an IO
and issue an IO command but proceed. After a while, the device from which IO was
sought is ready to communicate. In that case the device may raise an interrupt. This
would be a case of an external interrupt.
 Software Interrupt: Most OSs offer two modes of operation, the user mode and the
system mode. Whenever a user program makes a system call, be it for IO or a special
service, the operation must have a transition from user mode to system mode. An
interrupt is raised to effect this transition from user to system mode of operation. Such an
interrupt is called a software interrupt.

4. Direct Memory Access (DMA) Mode.

This is a mode of data transfer in which IO is performed in large data blocks. For instance, the
disks communicate in data blocks of sizes like 512 bytes or 1024 bytes. The direct memory
access, or DMA ensures access to main memory without processor intervention or support. Such
independence from processor makes this mode of transfer extremely efficient.
When a process initiates a direct memory access (DMA) transfer, its execution is briefly
suspended (using an interrupt) to set up the DMA control. The DMA control requires the
information on starting address in main memory and size of data for transfer. This information is
stored in DMA controller. Following the DMA set up, the program resumes from the point of
suspension. The device communicates with main memory stealing memory access cycles in
competition with other devices and processor. Figure 3.3 shows the hardware support.

Figure 3.3: DMA : Hardware support

Let us briefly describe the operations shown in Figure 3.3. Also, we shall assume a case of disk
to main memory transfer in DMA mode. We first note that there is a disk controller to regulate
communication from one or more disk drives. This controller essentially isolates individual
devices from direct communication with the CPU or main memory. The communication is
regulated to first happen between the device and the controller, and later between the controller
and main memory or CPU if so needed. Note that these devices communicate in blocks of bits or
bytes as a data stream. Clearly, an unbuffered communication is infeasible via the data bus. The
bus has its own timing control protocol. The bus cannot, and should not, be tied to device
transfer bursts. The byte stream block needs to be stored in a buffer isolated from the
communication to processor or main memory. This is precisely what the buffer in the disk
controller accomplishes.
Once the controller buffer has the required data, then one can envisage to put the controller in
contention with CPU and main memory or CPU to obtain an access to the bus. Thus if the
controller can get the bus then by using the address and data bus it can directly communicate
with main memory. This transfer shall be completely independent of program control from the
processor. So we can effect a transfer of one block of data from the controller to main memory
provided the controller has the address where data needs to be transferred and data count of the
transfer required. This is the kind of information which initially needs to be set up in the
controller address and count registers. Putting this information may be done under a program
control as a part of DMA set up. The program that does it is usually the device controller. The
device controller can then schedule the operations with much finer control. Data location
information in disk

Figure 3.4: DMA : Direct memory access mode of data transfer.

Let us now recap the above mode of transfer within a logical framework with a step-bystep
description. This procedure can be understood in the context of Figure 3.4. In the figure a few
lines do not have an accompanying label. However, by following the numbered sequence and its
corresponding label, one can find the nature of the operations considered.
The procedure can be understood by following the description given below:
We shall assume that we have a program P which needs to communicate with a device
D and get a chunk of data D to be finally stored starting in address A. The reader should follow
through the steps by correlating the numbers in Figure 3.4.
1. The program makes a DMA set-up request.
2. The program deposits the address value A and the data count D.the program also indicates the
virtual memory address of the data on disk.
3. The DMA controller records the receipt of relevant information and acknowledges the DMA
complete.
4. The device communicates the data to the controller buffer.
5. The controller grabs the address bus and data bus to store the data, one word at a
time.
6. The data count is decremented.
7. The above cycle is repeated till the desired data transfer is accomplished. At
which time a DMA data transfer complete signal is sent to the process.
The network-oriented traffic (between machines) may be handled in DMA mode. This is
so because the network cards are often DMA enabled. Besides, the network traffic usually
corresponds to getting information from a disk file at both the ends. Also, because network
traffic is in bursts, i.e. there are short intervals of large data transfers. DMA is
the most preferred mode of communication to support network traffic.

FILE MANAGEMENT SYSTEM

The file management system, FMS is the subsystem of an operating system that manages the data
storage organisation on secondary storage, and provides services to processes related to their
access. In this sense, it interfaces the application programs with the low-level media-I/O (e.g.
disk I/O) subsystem, freeing on the application programmers from having to deal with low-level
intricacies and allowing them to implement I/O using convenient data-organisational abstractions
such as files and records. On the other hand, the FMS services often are the only ways through
which applications can access the data stored in the files, thus achieving an encapsulation of the
data themselves which can be
usefully exploited for the purposes of data protection, maintenance and
control.
Typically, the only way that a user or application may access files is through the file
management system. This relieves the user or programmer of the necessity of developing special
-purpose software for each application and provides the system with a consistent, well-defined
means of controlling its most important asset.
Objectives of File Management System
The objectives of a File Management System as follows:
1. Data Management. An FMS should provide data management services to applications
through convenient abstractions, simplifying and making device-independent of the
common operations involved in data access and modification.
2. Generality with respect to storage devices. The FMS data abstractions and access
methods should remain unchanged irrespective of the devices involved in data storage.
3. Validity. An FMS should guarantee that at any given moment the stored data reflect the
operations performed on them, regardless of the time delays involved in actually
performing those operations. Appropriate access synchronization mechanism should be
used to enforce validity when multiple accesses from independent processes are possible.
4. Protection. Illegal or potentially dangerous operations on the
data should be controlled by the FMS, by enforcing a well
defined data protection policy.
 5. Concurrency. In multiprogramming systems, concurrent access to the data should be
allowed with minimal differences with respect to single-process access, save for access
synchronization enforcement.
6. Performance. The above functionalities should be offered achieving at the same a good
compromise in terms of data access speed and data transferring rate.

File Management Functions

With respect to meeting user requirements, the extent of such requirements depends on the
variety of applications and the environment in which the computer system will be used. For an
interactive, generalpurpose system, the under listed constitutes a minimal set of requirements:
a. Each user should be able to create, delete, read, write, and modify files.
b. Each user may have controlled access to other users’ files.
c. Each user may control what types of accesses are allowed to the user’s files.
d. Each user should be able to restructure the user’s files in a form appropriate to the
problem.
e. Each user should be able to move data between files.
f. Each user should be able to back up and recover the user’s files in case of damage.
g. Each user should be able to access his or her files by name rather than by numeric
identifier.
File System Architecture
One way of getting a feel for the scope of file management is to look at a depiction of a typical
software organisation, as suggested in Figure 2.
Of course, different systems will be organised differently, but this organisation is reasonably
representative.

1. Device Drivers
At the lowest level, device drivers communicate directly with peripheral devices or their
controllers or channels. A device driver is responsible for starting I/O operations on a device and
processing the completion of an I/O request. For file operations, the typical devices controlled
are disk and tape drives. Device drivers are usually considered to be part of the operating system.
2. Basic File System
The next level is referred to as the basic file system, or the physical I/O level. This is the
primary interface with the environment outside of the computer system. It deals with blocks of
data that are exchanged with disk or tape systems. Thus, it is concerned with the placement of
those blocks on the secondary storage device and on the buffering of those blocks in main
memory. It does not understand the contents of the data
or the structure of the files involved. The basic file system is often considered part of the
operating system.
3. Basic I/O Supervisor
The basic I/O supervisor is responsible for all file I/O initiation and termination. At this level,
control structures are maintained that deal with device I/O, scheduling, and file status. The basic
I/O supervisor selects the device on which file I/O is to be performed, based on the particular file
selected. It is also concerned with scheduling disk and
tape accesses to optimize performance. I/O buffers are assigned and secondary memory is
allocated at this level. The basic I/O supervisor is part of the operating system.
4. Logical I/O
Logical I/O enables users and applications to access records. Thus, whereas the basic file system
deals with blocks of data, the logical I/O module deals with file records. Logical I/O provides a
general-purpose record I/O capability and maintains basic data about files. The level of the file
system closest to the user is often termed the access method. It provides a standard interface
between applications and the file systems and devices that hold the data. Different access
methods reflect different file structures and different ways of accessing and processing the data.
Some of the most common access methods are shown in Figure 01, and they have been described
in the previous unit.
Elements of File Management
Another way of viewing the functions of a file system is shown in Figure 03. Let us follow this
diagram from left to right. Users and application programs interact with the file system by means
of commands for creating and deleting files and for performing operations on files. Before
performing any operation, the file system must identify and locate the selected file. This requires
the use of some sort of directory that serves to describe the location of all files, plus their
attributes. In addition, most shared systems enforce user access control:
Only authorised users are allowed to access particular files in particular
ways.
The basic operations that a user or application may perform on a file are performed at the record
level. The user or application views the file as having some structure that organises the records,
such as a sequential structure (e.g., personnel records are stored alphabetically by last name).
Thus, to translate user commands into specific file manipulation commands, the access method
appropriate to this file structure must be employed. Whereas users and applications are
concerned with records or fields, I/O is done on a block basis. Thus, the records or fields of a file
must be organised as a sequence of blocks for output and unblocked after input. To support block
I/O of files, several functions are needed.
The secondary storage must be managed. This involves allocating files to free blocks on
secondary storage and managing free storage so as to know what blocks are available for new
files and growth in existing files. In addition, individual block I/O requests must be scheduled.
Both disk scheduling and file allocation are concerned with optimising
performance. As might be expected, these functions therefore need to be considered together.
Furthermore, the optimisation will depend on the structure of the files and the access patterns.
Accordingly, developing an optimum file management system from the point of view of
performance is an exceedingly complicated task.
Figure 3 suggests a division between what might be considered the concerns of the file
management system as a separate system utility and the concerns of the operating system, with
the point of intersection being record processing. This division is arbitrary; various approaches
are taken in various systems
Operations Supported by File Management System
Users and applications wish to make use of files. Typical operations that must be supported
include the following:
1. Retrieve _All
Retrieve all the records of a file. This will be required for an application that must process all of
the information in the file at one time. For example, an application that produces a summary of
the information in the file would need to retrieve all records. This operation is often equated with
the term sequential processing, because all of the records
are accessed in sequence.
2. Retrieve _One
This requires the retrieval of just a single record. Interactive, transaction-oriented applications
need this operation.
3. Retrieve _Next
This requires the retrieval of the record that is “next” in some logical sequence to the most
recently retrieved record. Some interactive applications, such as filling in forms, may require
such an operation. A program that is performing a search may also use this operation.
4. Retrieve _Previous
Similar to Retrieve_Next, but in this case the record that is “previous” to the currently accessed
record is retrieved.
5. Insert _One
Insert a new record into the file. It may be necessary that the new record fit into a particular
position to preserve a sequencing of the file.
6. Delete_One
Delete an existing record. Certain linkages or other data structures may need to be updated to
preserve the sequencing of the file.
7. Update_One
Retrieve a record, update one or more of its fields, and rewrite the updated record back into the
file. Again, it may be necessary to preserve sequencing with this operation. If the length of the
record has changed, the update operation is generally more difficult than if the length is
preserved.
8. Retrieve_Few
Retrieve a number of records. For example, an application or user may wish to retrieve all
records that satisfy a certain set of criteria.
The nature of the operations that are most commonly performed on a file will influence the way
the file is organized, as discussed under file organisation, which in the next unit. It should be
noted that not all file systems exhibit the sort of structure discussed in this subsection. On UNIX
and UNIX-like systems, the basic file structure is just a stream of
bytes. For example, a C program is stored as a file but does not have physical fields, records, and
so on.