QUESTION ONE;

1. DISCUSS THE ROLES OF OS IN DEVICE MANAGEMENT.

Device management in an operating system means controlling the Input/Output devices like disk,
microphone, keyboard, printer, magnetic tape, USB ports, camcorder, scanner, other accessories,
and supporting units like supporting units control channels. A process may require various
resources, including main memory, file access, and access to disk drives, and others. If resources
are available, they could be allocated, and control returned to the CPU. Otherwise, the procedure
would have to be postponed until adequate resources become available. The system has multiple
devices, and in order to handle these physical or virtual devices, the operating system requires a
separate program known as an ad device controller. It also determines whether the requested
device is available.

The fundamentals of I/O devices may be divided into three categories:

1. Boot Device- It stores data in fixed-size blocks, each with its unique address. For
example- Disks.
2. Character Device- It transmits or accepts a stream of characters, none of which can be
addressed individually. For instance, keyboards, printers, etc.
3. Network Device- It is used for transmitting the data packets.

Functions of the device management in the operating system

The operating system (OS) handles communication with the devices via their drivers. The OS
component gives a uniform interface for accessing devices with various physical features. There
are various functions of device management in the operating system. Some of them are as
follows:

1. It keeps track of data, status, location, uses, etc. The file system is a term used to define a
group of facilities.
2. It enforces the pre-determined policies and decides which process receives the device
when and for how long.
3. It improves the performance of specific devices.
 4. It monitors the status of every device, including printers, storage drivers, and other
devices.
5. It allocates and effectively deallocates the device. De-allocating differentiates the devices
at two levels: first, when an I/O command is issued and temporarily freed. Second, when
the job is completed, and the device is permanently release

Types of devices

There are three types of Operating system peripheral devices: dedicated, shared, and virtual.
These are as follows:

1. Dedicated Device

In device management, some devices are allocated or assigned to only one task at a time until
that job releases them. Devices such as plotters, printers, tape drivers, and other similar devices
necessitate such an allocation mechanism because it will be inconvenient if multiple people share
them simultaneously. The disadvantage of such devices is the inefficiency caused by allocating
the device to a single user for the whole duration of task execution, even if the device is not used
100% of the time.

2. Shared Devices

These devices could be assigned to a variety of processes. By interleaving their requests, disk-
DASD could be shared by multiple processes simultaneously. The Device Manager carefully
controls the interleaving, and pre-determined policies must resolve all difficulties.

3. Virtual Devices

Virtual devices are a hybrid of the two devices, and they are dedicated devices that have been
transformed into shared devices. For example, a printer can be transformed into a shareable
device by using a spooling program that redirects all print requests to a disk. A print job is not
sent directly to the printer; however, it is routed to the disk until it is fully prepared with all of
the required sequences and formatting, at which point it is transmitted to the printers. The
approach can transform a single printer into numerous virtual printers, improving performance
and ease of use.
Features of Device Management

Here, you will learn the features of device management in the operating system. Various features
of the device management are as follows:

The OS interacts with the device controllers via the device drivers while allocating the device to
the multiple processes executing on the system.

Device drivers can also be thought of as system software programs that bridge processes and
device controllers.

The device management function's other key job is to implement the API.

Device drivers are software programs that allow an operating system to control the operation of
numerous devices effectively.

The device controller used in device management operations mainly contains three registers:
command, status, and data.
QUESTION TWO;

USING AN ILLUSTRATION EXPLAIN THE OPERATING SYSTEM I/O SUBSYSTEM.

I/O software is often organized in the following layers −

1. User Level Libraries − This provides simple interface to the user program to perform
input and output. For example, stdio is a library provided by C and C++ programming
languages.
2. Kernel Level Modules − This provides device driver to interact with the device
controller and device independent I/O modules used by the device drivers.
3. Hardware − This layer includes actual hardware and hardware controller which interact
with the device drivers and makes hardware alive.

A key concept in the design of I/O software is that it should be device independent where it
should be possible to write programs that can access any I/O device without having to specify the
device in advance. For example, a program that reads a file as input should be able to read a file
on a floppy disk, on a hard disk, or on a CD-ROM, without having to modify the program for
each different device.
Device Drivers

Device drivers are software modules that can be plugged into an OS to handle a particular
device. Operating System takes help from device drivers to handle all I/O devices. Device
drivers encapsulate device-dependent code and implement a standard interface in such a way that
code contains device-specific register reads/writes. Device driver, is generally written by the
device's manufacturer and delivered along with the device on a CD-ROM.

A device driver performs the following jobs −

1. To accept request from the device independent software above to it.

2. Interact with the device controller to take and give I/O and perform required error
handling
3. Making sure that the request is executed successfully
How a device driver handles a request is as follows: Suppose a request comes to read a block N.
If the driver is idle at the time a request arrives, it starts carrying out the request immediately.
Otherwise, if the driver is already busy with some other request, it places the new request in the
queue of pending requests.

Interrupt handlers

An interrupt handler, also known as an interrupt service routine or ISR, is a piece of software or
more specifically a callback function in an operating system or more specifically in a device
driver, whose execution is triggered by the reception of an interrupt.

When the interrupt happens, the interrupt procedure does whatever it has to in order to handle the
interrupt, updates data structures and wakes up process that was waiting for an interrupt to
happen.

The interrupt mechanism accepts an address ─ a number that selects a specific interrupt handling
routine/function from a small set. In most architectures, this address is an offset stored in a table
called the interrupt vector table. This vector contains the memory addresses of specialized
interrupt handlers.

Device-Independent I/O Software

The basic function of the device-independent software is to perform the I/O functions that are
common to all devices and to provide a uniform interface to the user-level software. Though it is
difficult to write completely device independent software but we can write some modules which
are common among all the devices. Following is a list of functions of device-independent I/O
Software −

1. Uniform interfacing for device drivers

2. Device naming - Mnemonic names mapped to Major and Minor device numbers
 3. Device protection
4. Providing a device-independent block size
5. Buffering because data coming off a device cannot be stored in final destination.
6. Storage allocation on block devices
7. Allocation and releasing dedicated devices
8. Error Reporting

User-Space I/O Software

These are the libraries which provide richer and simplified interface to access the functionality of
the kernel or ultimately interactive with the device drivers. Most of the user-level I/O software
consists of library procedures with some exception like spooling system which is a way of
dealing with dedicated I/O devices in a multiprogramming system.

I/O Libraries (e.g., stdio) are in user-space to provide an interface to the OS resident device-
independent I/O SW. For example putchar(), getchar(), printf() and scanf() are example of user
level I/O library stdio available in C programming.

Kernel I/O Subsystem

Kernel I/O Subsystem is responsible to provide many services related to I/O. Following are some
of the services provided.

 Scheduling − Kernel schedules a set of I/O requests to determine a good order in which to
execute them. When an application issues a blocking I/O system call, the request is
placed on the queue for that device. The Kernel I/O scheduler rearranges the order of the
queue to improve the overall system efficiency and the average response time
experienced by the applications.
 Buffering − Kernel I/O Subsystem maintains a memory area known as buffer that stores
data while they are transferred between two devices or between a device with an
application operation. Buffering is done to cope with a speed mismatch between the
producer and consumer of a data stream or to adapt between devices that have different
data transfer sizes.
 Caching − Kernel maintains cache memory which is region of fast memory that holds
copies of data. Access to the cached copy is more efficient than access to the original.
 Spooling and Device Reservation − A spool is a buffer that holds output for a device,
such as a printer, that cannot accept interleaved data streams. The spooling system copies
the queued spool files to the printer one at a time. In some operating systems, spooling is
managed by a system daemon process. In other operating systems, it is handled by an in-
kernel thread.
 Error Handling − An operating system that uses protected memory can guard against
many kinds of hardware and application errors.
QUESTION THREE;

EXPLAIN THE ADVANTAGES OF PLACING FUNCTIONALITY IN DEVICE

CONTROLLER RATHER THAN IN A KERNEL.

1. Bugs are less likely to cause an operating system crash.

2. Performance or execution can be improved by utilizing dedicated or committed hardware
and hard-coded algorithms or calculations.
3. The kernel is simplified or disentangled by moving algorithms out of it.

QUESTION FOUR:

EXPLAIN THE ADVANTAGES AND DISADVANTAGES OF SUPPORTING MEMORY

MAPPED I/O TO DEVICE CONTROL REGISTERS.

ADVANTAGES;

1. Supporting memory-mapped I/O does not require special I/O instructions from the
instruction set. So, it does not require enforcement of rules that prevent user programs
from executing these I/O. Hence advantageous over device control registers.
2. Memory mapped I/O gives you a single address space and a common set of instructions
for both data and I/O operations.
3. You can define memory ordering rules and memory barriers that apply both to device
accesses and normal memory.
4. You don’t need a whole separate set of opcodes for I/O instructions. You can reuse your
ordinary memory access instructions.
5. You can use pointers in languages such as C and C++ to access devices, rather than
platform-specific intrinsics or inline assembly. Caveats:
6. You still need to tag those pointers volatile.
7. You may still need intrinsics or inline assembly to implement memory barriers.
8. You can reuse the same memory mapping mechanisms you use for other memory to
control access to devices (e.g. page table entries).
 9. You may benefit from much of the low-latency buses and request routing infrastructure
put in place to optimize normal data accesses.

DISADVANTAGES;

1. The resulting flexibility needs to be handled with care. To ensure protection, memory
translation units need to ensure that user programs are not able to access memory
associated with the device control register.
2. It potentially complicates your cache controller, as device accesses behave differently
from normal memory accesses.
3. It potentially complicates instruction scheduling (especially speculation) as the processor
doesn’t know immediately that a given load or store goes to device memory; rather, the
MMU or some other structure in or near the memory system informs it once it receives
and decodes the address.
4. It adds corner conditions and restrictions, such as requiring certain specific access widths
(e.g. 32-bit writes only; no 8-bit, 16-bit, or 64-bit writes), which may catch some
compilers by surprise.
5. You still end up with high access latency and lower throughput when your request steps
off the fast, low-latency path meant for data into an I/O subsystem with slower, simpler
buses.
6. You can get some nasty surprises when you use types such as std::atomic to perform
MMIO, and discover the compiler uses an instruction that isn’t compatible with your
peripheral. (In the case I’m thinking of, it was a MOV upgraded to XCHG, which made a
PCIe peripheral cranky.)
2. EXPLAIN THE OPERATING SYSTEMS RESPONSIBILITIES IN DISK
MANAGEMENT.
3. ELABORATE THE SWAP-SPACE MANAGEMENT CONCEPT HIGHLIGHTING
HOW THE OPERATING SYSTEM ACHIEVES THIS.