ICS 2305 SYSTEMS PROGRAMMING Programming of operating system modules; input/output management, process control and management, context

switching. Process control. Device drivers. Device independence. Signal handling. Memory management. File management. File and directories. Real time clock management. Inter-processes and inter-machine communication.

2.0 INPUT / OUTPUT MANAGEMENT

Management Data Input/Output, or MDIO, is a serial bus defined for the Ethernet IEEE 802.3 specification for Media Independent Interface, or MII. The MII connects Media Access Control (MAC) devices with physical bus interface, or PHY, circuits. The MII comprises: -a data interface to the Ethernet link and -a management interface, referred as MDIO or as Media Independent Interface Management (MIIM). The MDIO bus provides access to the configuration & status registers of each PHY. These registers are used to initially configure each PHY and also to monitor status during operation.

3. ELECTRICAL SPECIFICATION
The MDIO interface is implemented by two lines: -a MDC clock line and -an MDIO data line The clock line is driven by the MAC device. The data line is bidirectional: the PHY drives it to provide register data at the end of a read operation. The bus has a single MAC master, but can have up to 31 PHY slaves. The MDC clock can be a periodic, with a minimum period of 400 ns, which corresponds to a maximal frequency of 2.5 MHz. Newer chips, however, allow faster accesses. The MDIO data line has a pull-up of 1.5 kOhm in the PHY, allowing the MAC to determine if one or more PHYs are attached. The MAC should have a 2 kOhm pull-down on that same line.

BUS TIMING
Between two accesses, the MAC and the PHY can drive the MDIO line tri-state. Before a register access, PHY devices generally require a preamble of 32 ones on the MDIO line. The accesses are made out of 16 control bits followed by 16 data bits. The control bits specify the access type (read or write), the PHY address and the register address. 1

During a write command, the MAC provides control and data. In the case of a read command, the PHY takes over the bus at the end of the cycle and supplies the MAC with the data.

REGISTERS
The "Clause 22" MDIO interface specifies 5 PHY address bits which account for up to 32 devices and 5 register address bits which allows up to 32 registers. The function of the registers is left free for the manufacturer to specify. The 802.3ae (10 gigabit Ethernet) "Clause 45" interface can access up to 65536 registers in 32 different devices. These features were added for 10G ethernet and use different opcodes and start sequences.

PROCESS CONTROL AND MANAGEMENT PROCESS CONTROL BLOCK

A Process Control Block (PCB, also called Task Controlling Block or Task Struct) is a data structure in the operating system kernel containing the information needed to manage a particular process. The PCB is "the manifestation of a process in an operating system".

INCLUDED INFORMATION
2

Implementations differ, but in general a PCB will include, directly or indirectly: -The identifier of the process (a process identifier, or PID) -Register values for the process including, notably, the program counter and stack pointer values for the process. -The address space for the process -Priority (in which higher priority process gets first preference. eg., nice value on Unix operating systems) -Process accounting information, such as when the process was last run, how much CPU time it has accumulated, etc. -Pointer to the next PCB i.e. pointer to the PCB of the next process to run -I/O Information (i.e. I/O devices allocated to this process, list of opened files, etc) During context switch, the running process is stopped and another process is given a chance to run. The kernel must stop the execution of the running process, copy out the values in hardware registers to its PCB, and update the hardware registers with the values from the PCB of the new process.

LOCATION OF THE PCB

Since PCB contains the critical information for the process, it must be kept in an area of memory protected from normal user access. In some operating systems the PCB is placed in the beginning of the kernel stack of the process since that is a convenient protected location.

PROCESS MANAGEMENT
Process management is an integral part of any modern day operating system (OS). The OS must allocate resources to processes, enable processes to share and exchange information, protect the resources of each process from other processes and enable synchronisation among processes. To meet these requirements, the OS must maintain a data structure for each process, which describes 3

the state and resource ownership of that process, and which enables the OS to exert control over each process.

MULTIPROGRAMMING
In many modern operating systems, there can be more than one instance of a program loaded in memory at the same time; for example, more than one user could be executing the same program, each user having separate copies of the program loaded into memory. With some programs, it is possible to have one copy loaded into memory, while several users have shared access to it so that they each can execute the same program-code. Such a program is said to be re-entrant. The processor at any instant can only be executing one instruction from one program but several processes can be sustained over a period of time by assigning each process to the processor at intervals while the remainder become temporarily inactive. A number of processes being executed over a period of time instead of at the same time is called concurrent execution. A multiprogramming or multitasking OS is a system executing many processes concurrently. Multiprogramming requires that the processor be allocated to each process for a period of time and de-allocated at an appropriate moment. If the processor is de-allocated during the execution of a process, it must be done in such a way that it can be restarted later as easily as possible. 4

There are two possible ways for an OS to regain control of the processor during a programs execution in order for the OS to perform de-allocation or allocation: 1. The process issues a system call (sometimes called a software interrupt); for example, an I/O request occurs requesting to access a file on hard disk. 2. A hardware interrupt occurs; for example, a key was pressed on the keyboard, or a timer runs out (used in pre-emptive multitasking). The stopping of one process and starting (or restarting) of another process is called a context switch or context change. In many modern operating systems, processes can consist of many sub-processes. This introduces the concept of a thread. A thread may be viewed as a subprocess; that is, a separate, independent sequence of execution within the code of one process. Threads are becoming increasingly important in the design of distributed and clientserver systems and in software run on multi-processor systems.

HOW MULTIPROGRAMMING INCREASES EFFICIENCY

A common trait observed among processes associated with most computer programs, is that they alternate between CPU cycles and I/O cycles. For the portion of the time required for CPU cycles, the process is being executed; i.e. is occupying the CPU. During the time required for I/O cycles, the process is not using the processor. Instead, it is either waiting to perform Input/Output, or is actually performing Input/Output. An example of this is the reading from or writing to a file on disk. Prior to the advent of multiprogramming, computers operated as singleuser systems. Users of such systems quickly became aware that for much of the time that a computer was allocated to a single user, the processor was idle; when the user was entering information or debugging programs for example. Computer scientists observed that overall performance of the machine could be improved by letting a different process use the processor whenever one process was waiting for input/output. In a uni-programming system, if N users were to execute programs with individual execution times of t1, t2, ..., tN, then the total time, tuni, to service the N processes (consecutively) of all N users would be: tuni = t1 + t2 + ... + tN.

However, because each process consumes both CPU cycles and I/O cycles, the time which each process actually uses the CPU is a very small fraction of the total execution time for the process. So, for process i: ti (processor) ti (execution) where ti (processor) is the time process i spends using the CPU, and ti (execution) is the total execution time for the process; i.e. the time for CPU cycles plus I/O cycles to be carried out (executed) until completion of the process. In fact, usually the sum of all the processor time, used by N processes, rarely exceeds a small fraction of the time to execute any one of the processes;

Therefore, in uni-programming systems, the processor lay idle for a considerable proportion of the time. To overcome this inefficiency, multiprogramming is now implemented in modern operating systems such as Linux, UNIX and Microsoft Windows. This enables the processor to switch from one process, X, to another, Y, whenever X is involved in the I/O phase of its execution. Since the processing time is much less than a single job's runtime, the total time to service all N users with a multiprogramming system can be reduced to approximately: tmulti = max(t1, t2, ..., tN)

PROCESS CREATION
Operating systems need some ways to create processes. In a very simple system designed for running only a single application (e.g., the controller in a microwave oven), it may be possible to have all the processes that will ever be needed be present when the system comes up. In generalpurpose systems, however, some way is needed to create and terminate processes as needed during operation. There are four principal events that cause a process to be created: 6

System initialization. Execution of process creation system call by running a process. A user request to create a new process. Initiation of a batch job.

When an operating system is booted, typically several processes are created. Some of these are foreground processes, that interacts with a (human) user and perform work for them. Other are background processes, which are not associated with particular users, but instead have some specific function. For example, one background process may be designed to accept incoming emails, sleeping most of the day but suddenly springing to life when an incoming e-mail arrives. Another background process may be designed to accept an incoming request for web pages hosted on the machine, waking up when a request arrives to service that request. Process creation in UNIX and Linux are done through fork() or clone() system calls. There are several steps involved in process creation. The first step is the validation of whether the parent process has sufficient authorization to create a process. Upon successful validation, the parent process is copied almost entirely, with changes only to the unique process id, parent process, and user-space. Each new process gets its own user space.

PROCESS TERMINATION
There are many reasons for process termination: -Batch job issues halt instruction -User logs off -Process executes a service request to terminate -Error and fault conditions -Normal completion -Time limit exceeded -Memory unavailable -Bounds violation; for example: attempted access of (non-existent) 11th element of a 10element array 7

-Protection error; for example: attempted write to read-only file -Arithmetic error; for example: attempted division by zero -Time overrun; for example: process waited longer than a specified maximum for an event -I/O failure -Invalid instruction; for example: when a process tries to execute data (text) -Privileged instruction -Data misuse -Operating system intervention; for example: to resolve a deadlock -Parent terminates so child processes terminate (cascading termination) -Parent request

TWO-STATE PROCESS MANAGEMENT MODEL

The operating systems principal responsibility is in controlling the execution of processes. This includes determining the interleaving pattern for execution and allocation of resources to processes. One part of designing an OS is to describe the behaviour that we would like each process to exhibit. The simplest model is based on the fact that a process is either being executed by a processor or it is not. Thus, a process may be considered to be in one of two states, RUNNING or NOT RUNNING. When the operating system creates a new process, that process is initially labeled as NOT RUNNING, and is placed into a queue in the system in the NOT RUNNING state. The process (or some portion of it) then exists in main memory, and it waits in the queue for an opportunity to be executed. After some period of time, the currently RUNNING process will be interrupted, and moved from the RUNNING state to the NOT RUNNING state, making the processor available for a different process. The dispatch portion of the OS will then select, from the queue of NOT RUNNING processes, one of the waiting processes to transfer to the processor. The chosen process is then relabeled from a NOT RUNNING state to a RUNNING state, and its execution is either begun if it is a new process, or is resumed if it is a process which was interrupted at an earlier time. From this model we can identify some design elements of the OS: 8

-The need to represent, and keep track of each process. -The state of a process. -The queuing of NON RUNNING processes

THREE-STATE PROCESS MANAGEMENT MODEL

Although the two-state process management model is a perfectly valid design for an operating system, the absence of a BLOCKED state means that the processor lies idle when the active process changes from CPU cycles to I/O cycles. This design does not make efficient use of the processor. The three-state process management model is designed to overcome this problem, by introducing a new state called the BLOCKED state. This state describes any process which is waiting for an I/O event to take place. In this case, an I/O event can mean the use of some device or a signal from another process. The three states in this model are: -RUNNING: The process that is currently being executed. -READY: A process that is queuing and prepared to execute when given the opportunity. -BLOCKED: A process that cannot execute until some event occurs, such as the completion of an I/O operation. At any instant, a process is in one and only one of the three states. For a single processor computer, only one process can be in the RUNNING state at any one instant. There can be many processes in the READY and BLOCKED states, and each of these states will have an associated queue for processes. Processes entering the system must go initially into the READY state, processes can only enter the RUNNING state via the READY state. Processes normally leave the system from the RUNNING state. For each of the three states, the process occupies space in main memory. While the reason for most transitions from one state to another might be obvious, some may not be so clear. -RUNNING - READY The most common reason for this transition is that the running process has reached the maximum allowable time for uninterrupted execution; i.e. time-out occurs. Other reasons can be the imposition of priority levels as determined by the scheduling policy used for the Low Level Scheduler, and the arrival of a higher priority process into the READY state. 9

-RUNNING - BLOCKED A process is put into the BLOCKED state if it requests something for which it must wait. A request to the OS is usually in the form of a system call, (i.e. a call from the running process to a function that is part of the OS code). For example, requesting a file from disk or a saving a section of code or data from memory to a file on disk.

FIVE-STATE PROCESS MANAGEMENT MODEL

While the three state model is sufficient to describe the behavior of processes with the given events, we have to extend the model to allow for other possible events, and for more sophisticated design. In particular, the use of a portion of the hard disk to emulate main memory (so called virtual memory) requires additional states to describe the state of processes which are suspended from main memory, and placed in virtual memory (on disk). Of course, such processes can, at a future time, be resumed by being transferred back into main memory. The Medium Level Scheduler controls these events. A process can be suspended from the RUNNING, READY or BLOCKED state, giving rise to two other states, namely, READY SUSPEND and BLOCKED SUSPEND. A RUNNING process that is suspended becomes READY SUSPEND, and a BLOCKED process that is suspended becomes BLOCKED SUSPEND. A process can be suspended for a number of reasons; the most significant of which arises from the process being swapped out of memory by the memory management system in order to free memory for other processes. Other common reasons for a process being suspended are when one suspends execution while debugging a program, or when the system is monitoring processes. For the five-state process management model, consider the following transitions described in the next sections. -BLOCKED - BLOCKED SUSPEND If a process in the RUNNING state requires more memory, then at least one BLOCKED process can be swapped out of memory onto disk. The transition can also be made for the BLOCKED process if there are READY processes available, and the OS determines that the READY process that it would like to dispatch requires more main memory to maintain adequate performance. -BLOCKED SUSPEND - READY SUSPEND A process in the BLOCKED SUSPEND state is moved to the READY SUSPEND state when the event for which it has been waiting occurs.

10

Note that this requires that the state information concerning suspended processes be accessible to the OS. -READY SUSPEND - READY When there are no READY processes in main memory, the OS will need to bring one in to continue execution. In addition, it might be the case that a process in the READY SUSPEND state has higher priority than any of the processes in the READY state. In that case, the OS designer may dictate that it is more important to get at the higher priority process than to minimise swapping. -READY - READY SUSPEND Normally, the OS would be designed so that the preference would be to suspend a BLOCKED process rather than a READY one. This is because the READY process can be executed as soon as the CPU becomes available for it, whereas the BLOCKED process is taking up main memory space and cannot be executed since it is waiting on some other event to occur. However, it may be necessary to suspend a READY process if that is the only way to free a sufficiently large block of main memory. Finally, the OS may choose to suspend a lower-priority READY process rather than a higher-priority BLOCKED process if it believes that the BLOCKED process will be ready soon.

PROCESS DESCRIPTION AND CONTROL

Each process in the system is represented by a data structure called a Process Control Block (PCB), or Process Descriptor in Linux, which performs the same function as a traveller's passport. The PCB contains the basic information about the job including: -What it is -Where it is going -How much of its processing has been completed -Where it is stored -How much it has spent in using resources Process Identification: Each process is uniquely identified by the users identification and a pointer connecting it to its descriptor. 11

Process Status: This indicates the current status of the process; READY, RUNNING, BLOCKED, READY SUSPEND, BLOCKED SUSPEND. Process State: This contains all of the information needed to indicate the current state of the job. Accounting: This contains information used mainly for billing purposes and for performance measurement. It indicates what kind of resources the process has used and for how long.

PROCESSOR MODES
Contemporary processors incorporate a mode bit to define the execution capability of a program in the processor. This bit can be set to kernel mode or user mode. Kernel mode is also commonly referred to as supervisor mode, monitor mode or ring 0. In kernel mode, the processor can execute every instruction in its hardware repertoire, whereas in user mode, it can only execute a subset of the instructions. Instructions that can be executed only in kernel mode are called kernel, privileged or protected instructions to distinguish them from the user mode instructions. For example, I/O instructions are privileged. So, if an application program executes in user mode, it cannot perform its own I/O. Instead, it must request the OS to perform I/O on its behalf. The system may logically extend the mode bit to define areas of memory to be used when the processor is in kernel mode versus user mode. If the mode bit is set to kernel mode, the process executing in the processor can access either the kernel or user partition of the memory. However, if user mode is set, the process can reference only the user memory space. We frequently refer to two classes of memory user space and system space (or kernel, supervisor or protected space). In general, the mode bit extends the operating system's protection rights. The mode bit is set by the user mode trap instruction, also called a supervisor call instruction. This instruction sets the mode bit, and branches to a fixed location in the system space. Since only system code is loaded in the system space, only system code can be invoked via a trap. When the OS has completed the supervisor call, it resets the mode bit to user mode prior to the return.

THE KERNEL CONCEPT

The parts of the OS critical to its correct operation execute in kernel mode, while other software (such as generic system software) and all application programs execute in user mode. This fundamental distinction is usually the irrefutable distinction between the operating system and 12

other system software. The part of the system executing in kernel supervisor state is called the kernel, or nucleus, of the operating system. The kernel operates as trusted software, meaning that when it was designed and implemented, it was intended to implement protection mechanisms that could not be covertly changed through the actions of untrusted software executing in user space. Extensions to the OS execute in user mode, so the OS does not rely on the correctness of those parts of the system software for correct operation of the OS. Hence, a fundamental design decision for any function to be incorporated into the OS is whether it needs to be implemented in the kernel. If it is implemented in the kernel, it will execute in kernel (supervisor) space, and have access to other parts of the kernel. It will also be trusted software by the other parts of the kernel. If the function is implemented to execute in user mode, it will have no access to kernel data structures. However, the advantage is that it will normally require very limited effort to invoke the function. While kernel-implemented functions may be easy to implement, the trap mechanism and authentication at the time of the call are usually relatively expensive. The kernel code runs fast, but there is a large performance overhead in the actual call. This is a subtle, but important point.

REQUESTING SYSTEM SERVICES

There are two techniques by which a program executing in user mode can request the kernel's services: -System call -Message passing Operating systems are designed with one or the other of these two facilities, but not both. First, assume that a user process wishes to invoke a particular target system function. For the system call approach, the user process uses the trap instruction. The idea is that the system call should appear to be an ordinary procedure call to the application program; the OS provides a library of user functions with names corresponding to each actual system call. Each of these stub functions contains a trap to the OS function. When the application program calls the stub, it executes the trap instruction, which switches the CPU to kernel mode, and then branches (indirectly through an OS table), to the entry point of the function which is to be invoked. When the function

13

completes, it switches the processor to user mode and then returns control to the user process; thus simulating a normal procedure return. In the message passing approach, the user process constructs a message, that describes the desired service. Then it uses a trusted send function to pass the message to a trusted OS process. The send function serves the same purpose as the trap; that is, it carefully checks the message, switches the processor to kernel mode, and then delivers the message to a process that implements the target functions. Meanwhile, the user process waits for the result of the service request with a message receive operation. When the OS process completes the operation, it sends a message back to the user process. The distinction between the two approaches has important consequences regarding the relative independence of the OS behavior, from the application process behavior, and the resulting performance. As a rule of thumb, operating system based on a system call interface can be made more efficient than those requiring messages to be exchanged between distinct processes. This is the case, even though the system call must be implemented with a trap instruction; that is, even though the trap is relatively expensive to perform, it is more efficient than the message passing approach, where there are generally higher costs associated with process multiplexing, message formation and message copying. The system call approach has the interesting property that there is not necessarily any OS process. Instead, a process executing in user mode changes to kernel mode when it is executing kernel code, and switches back to user mode when it returns from the OS call. If, on the other hand, the OS is designed as a set of separate processes, it is usually easier to design it so that it gets control of the machine in special situations, than if the kernel is simply a collection of functions executed by users processes in kernel mode. Even procedurebased operating system usually find it necessary to include at least a few system processes (called daemons in UNIX) to handle situation whereby the machine is otherwise idle such as scheduling and handling the network.

3.0 CONTEXT SWITCHING

A context switch is the computing process of storing and restoring state (context) of a CPU so that execution can be resumed from the same point at a later time. This enables multiple processes to share a single CPU. The context switch is an essential feature of a multitasking 14

operating system. Context switches are usually computationally intensive and much of the design of operating systems is to optimize the use of context switches. A context switch can mean a register context switch, a task context switch, a thread context switch, or a process context switch. What constitutes the context is determined by the processor and the operating system. Switching from one process to another requires a certain amount of time for doing the administration - saving and loading registers and memory maps, updating various tables and list etc. A process runs on the CPU until it is context switched. This happens when one of the following occurs: -The process exits. -The process uses up its time slice. -The process requires another resource that is not currently available or needs to wait for I/O to complete. -A resource has become available for a sleeping process. If there is a higher priority process ready to run, the kernel will run this instead (the current process is preempted). -The process relinquishes the CPU using a semaphore or similar system call. The scheduler can only take a process off the CPU when returning to user mode from system mode, or if the process voluntarily relinquishes the CPU from system mode. If the process has used up its time slice or is preempted, it is returned to the run queue. If it cannot proceed without access to a resource such as disk I/O, it sleeps until the resource is available. Once access to that resource is available, the process is placed on the run queue before being put on the processor. ``Preemption of a process that goes to sleep waiting for I/O'' illustrates this for a process O[1] which goes to sleep waiting for I/O.

15

PREEMPTION OF A PROCESS THAT GOES TO SLEEP WAITING FOR I/O A context switch occurs when the kernel transfers control of the CPU from an executing process to another that is ready to run. The kernel first saves the context of the process. The context is the 16

set of CPU register values and other data that describes the process' state. The kernel then loads the context of the new process which then starts to execute. When the process that was taken off the CPU next runs, it resumes from the point at which it was taken off the CPU. This is possible because the saved context includes the instruction pointer. This indicates the point in the executable code that the CPU had reached when the context switch occurred.

WHEN TO SWITCH?
There are three situations where a context switch needs to occur. They are:

Multitasking
Most commonly, within some scheduling scheme, one process needs to be switched out of the CPU so another process can run. Within a preemptive multitasking operating system, the scheduler allows every task to run for some certain amount of time, called its time slice. If a process does not voluntarily yield the CPU (for example, by performing an I/O operation), a timer interrupt fires, and the operating system schedules another process for execution instead. This ensures that the CPU cannot be monopolized by any one processor-intensive application.

Interrupt Handling
Modern architectures are interrupt driven. This means that if the CPU requests data from a disk, for example, it does not need to busy-wait until the read is over; it can issue the request and continue with some other execution. When the read is over, the CPU can be interrupted and presented with the read. For interrupts, a program called an interrupt handler is installed, and it is the interrupt handler that handles the interrupt from the disk. The kernel services the interrupts in the context of the interrupted process even though it may not have caused the interrupt. The interrupted process may have been executing in user mode or in kernel mode. The kernel saves enough information so that it can later resume execution of the interrupted process and services the interrupt in kernel mode. The kernel does not spawn or schedule a special process to handle interrupts. 17

User and kernel mode switching

When a transition between user mode and kernel mode is required in an operating system, a context switch is not necessary; a mode transition is not by itself a context switch. However, depending on the operating system, a context switch may also take place at this time.

4.0 PROCESS CONTROL

Process control is a statistics and engineering discipline that deals with architectures, mechanisms and algorithms for maintaining the output of a specific process within a desired range. For example, heating up the temperature in a room is a process that has the specific, desired outcome to reach and maintain a defined temperature (e.g. 20C), kept constant over time. Here, the temperature is the controlled variable. At the same time, it is the input variable since it is measured by a thermometer and used to decide whether to heat or not to heat. The desired temperature (20C) is the setpoint. The state of the heater (e.g. the setting of the valve allowing hot water to flow through it) is called the manipulated variable since it is subject to control actions. A commonly used control device called a programmable logic controller, or a PLC, is used to read a set of digital and analog inputs, apply a set of logic statements, and generate a set of analog and digital outputs. Using the example in the previous paragraph, the room temperature would be an input to the PLC. The logical statements would compare the setpoint to the input temperature and determine whether more or less heating was necessary to keep the temperature constant. A PLC (Programmable Logic Controller) output would then either open or close the hot water valve, an incremental amount, depending on whether more or less hot water was needed. Larger more complex systems can be controlled by a Distributed Control System (DCS) or SCADA (supervisory control and data acquisition) system. In practice, process control systems can be characterized as one or more of the following forms: a)Discrete Found in many manufacturing, motion and packaging applications. Robotic assembly, such as that found in automotive production, can be characterized as discrete 18

process control. Most discrete manufacturing involves the production of discrete pieces of product, such as metal stamping. b)Batch Some applications require that specific quantities of raw materials be combined in specific ways for particular durations to produce an intermediate or end result. One example is the production of adhesives and glues, which normally require the mixing of raw materials in a heated vessel for a period of time to form a quantity of end product. Other important examples are the production of food, beverages and medicine. Batch processes are generally used to produce a relatively low to intermediate quantity of product per year (a few pounds to millions of pounds). c)Continuous Often, a physical system is represented through variables that are smooth and uninterrupted in time. The control of the water temperature in a heating jacket, for example, is an example of continuous process control. Some important continuous processes are the production of fuels, chemicals and plastics. Continuous processes in manufacturing are used to produce very large quantities of product per year (millions to billions of pounds). Applications having elements of discrete, batch and continuous process control are often called hybrid applications.

5.0 DEVICE DRIVERS

In computing, a device driver or software driver is a computer program allowing higher-level computer programs to interact with a hardware device. A driver typically communicates with the device through the computer bus or communications subsystem to which the hardware connects. When a calling program invokes a routine in the driver, the driver issues commands to the device. Once the device sends data back to the driver, the driver may invoke routines in the original calling program. Drivers are hardware-dependent and operating-system-specific. They usually provide the interrupt handling required for any necessary asynchronous time-dependent hardware interface.

PURPOSE
19

A device driver simplifies programming by acting as translator between a hardware device and the applications or operating systems that use it. Programmers can write the higher-level application code independently of whatever specific hardware device.

6.0 DEVICE INDEPENDENCE

20