I/O, Devices & Device Drivers

I/O subsystem

• It is the responsibility of the I/O subsystem of an OS to schedule, manage, & control the interactions between processes and devices.

• In a single/process user system if a program requests access to an I/O device it gains control of that device immediately, and the I/O subsystem manages the transfer of data

• In a multiprogramming environment, many processes can be requesting service from the same device. The I/O subsystem is then responsible for:– Determining if the device is available

• If it is the operation is initiated and handled by the I/O subsystem

– If the device is unavailable• The request is preserved in a device queue• When the device becomes available, the next pending

operation is initiated.

What is a device driver

• A device driver is software that manages communications with a specific I/O device or type of I/O device.

• Device drivers are one of the most frequently written type of OS software

• Implementing device drivers can be complex because of the characteristics of the individual device

 DEVICE CONTROL OPERATIONS DATA TRANSFER OPERATIONS

DiskInitializeSeek to Sector, Track, Cyl.Seek Home Position

Read blockWrite block

Magnetic Tape

RewindForward Space RecordBackspace Record

Read RecordWrite RecordRead Backwards

PrinterInitializeLoad or select fontSelect paper tray

Print characterLoad fontInitialize

Terminal **Read CharacterWrite Character

Mouse  Read positionRead button status

** Control operations are normally invoked by special characters in the data streamFigure 9--1: I/O Operations for Typical Devices

Character Devices

• These devices transfer one character at a time between the device and the computer.– Keyboards– Printers

Block Storage Devices

• Usually magnetic storage devices: magnetic tape and disks.

• These are devices that transfer large groups of bytes called blocks.

• Once an operation is started, it proceeds without further intervention by the OS.

Magnetic tapes are a continuous strip of storage medium which contains a # of parallel tracks. 8 bits of data are written in parallel on 8 tracks with a 9th track used for a parity bit. In this form, data may be written densely, maybe up to thousands of bytes per block. However and inch or more may be required between blocks for control information.

Usefulness of tape is limited by it serial nature.

track

sectorCircular base of support material on which a magnetic film is deposited.

Arm

CPU

I/O

Interface

controller

DeviceDevice

Driver

Data

Status

Control

Processors view of I/O

Separate and protected, accessed through special instructions ie: Inport and Outport

Memory mapped I/O

Implementation strategies for handling devices

• Simple I/O– AKA Programmed I/O– Used on small and medium sized computers

to handle character devices

• Block transfer– Used on small and medium sized computers

to handle block devices

• I/O processors – used on large computers

Polling .vs. Interrupts

• Once an I/O operation is initiated, the OS must tract the operation until it is complete.

• There are two techniques that can be used to monitor device activity: Polling or Interrupts

Simple Polling algorithm/* initialize pointer and index */

ix=0;count = BUFLEN;

/* begin polling loop */while ((count > 0) && (no device error)) {

/* wait while device is busy */while (device is busy) {}

/* process character if no error */if (no device error) {

write buffer[ix]; /* write next character */count = count - 1; /* decrement count */ix = ix + 1; /* increment index */

}}

• Using interrupts for device management:– Starting I/O– Returning to the process or OS– Device generates an interrupt signal

InterruptsMAIN PROGRAM:/* initialize index, count, and device flag */ix = 0;count = BUFLEN;dev_flag = 0;...enable interrupts for device and initiate operation.../* loop until all characters are written */while (dev_flag == 0) {}...INTERRUPT HANDLER:save registers/* check for errors */if (error) {dev_flag = -1; /* set flag to error code */disable interrupts for devicerestore registersreturn from interrupt}

Interrupts continued/* check for completion */if (count==0) { /* operation completed */dev_flag = 1; /* set flag to completion code */disable interrupts for devicerestore registersreturn from interrupt}

/* no error, not complete; process character */write buffer[ix]; /* write next character */ix = ix + 1; /* increment index */count = count - 1; /* decrement count */restore registersreturn from interrupt

Buffering

• Buffering is a technique that can be used to improve device as well as CPU throughput

• Buffering is the use of temporary storage areas in memory to store data that is read from an input device before it is needed. Process can also use buffering to store data before it is sent to the output device

Buffering with character devices

Ring Buffer

Buffering with DMA devices and blocking

BUFFER1

BUFFER2

DISK1

CPU/PROCESS

READ MORE DATA

PROCESS

Device

Driver

BUFFER1

BUFFER2

CPU/PROCESS

Read Last logical record from buffer 1

DISK1

Start read from device to fill buffer 2

Software Caching

Data structures for Device Management

• I/O operations that are in progress need to be represented by some type of data structures in every operating system

• This data structure can be called by various names DCB, IOB, IOCB

• It represents a device, channel or controller, and the activity of the device

Data structures for device management: I/OCB

Channel (port ) Number Controller AddressDevice NameDevice AddressInterrupt Vector AddressAddress of Interrupt HandlerDevice TypeAddress of Open ProcedureAddress of Close ProcedureAddress of Start I/O ProcedureAddress of Cancel I/O ProcedureBuffer AddressBuffer LengthCurrent Buffer PointerCurrent Data CountCurrent I/O OperationAddress of PCB of Process which requested the OperationAddress of I/O Request ParametersAddress of ECB for Current OperationFigure 10--15: Information Stored in an I/O Control Block & DCB

Device Driver Organization

• Every device driver & I/O supervisor must provide services to support the basic activities for each device, including:– Preparing for and starting I/O– Servicing interrupts– Completion of I/O– Cancellation of I/O– Error detection and recovery

• The I/O system call interface includes procedures to service common operations such as:– Open, close, read, write, and control operations

• Which when called for a specific device, invoke the corresponding component of a device driver.

Device driver organization: structure and functions of device drivers

Figure 10--17: Structure and Functions of Device Drivers

Figure 10--18: Flow of Control in a Device Driver

Parameters

• Individual standards for system calls and device drivers for a specific OS will determine how parameters are passed to device drivers.

• Most systems create a parameter list, using a register to point to the address of this list.

• Part of the responsibility of the I/O scheduler is to access these parameters, validate them, and make them available to later components of the device driver.

Preparing for I/O

• Preparation for I/O is the first activity of a device driver when invoked via one of the device system calls.

• I/O system call parameters must:– specify the type of operation requested (read, write, control), – the address of the data buffer to be used, – the size of the data area, – and other relevant information. (font, or paper tray)– Additionally, device-dependent parameters, such as track and sector numbers for disk operations, may also

be required.• This component of a device driver validates device-specific parameters of an I/O request.

Appropriate error return codes must be provided to the user for any errors detected in the service request parameters.

• The preparation for I/O might include:– temporary buffer allocation or initialization, – formatting of data, – placing information in the appropriate location(s) in some I/O control block that is accessible to the device

interrupt handler and the operating system. • Once the I/O request parameters are validated, the device status must be checked. If the device

is busy or not ready, the device driver must take an appropriate system dependent action. – If an error condition or problem such as "device not ready" is detected, the driver might take action causing

the application process to terminate, or it might simply provide a return code to be passed back to the process, which then must deal with the problem in a suitable way depending on the application.

– In a multiprogramming operating system, the response may include queuing the I/O request for a shared device that is presently busy with another operation.

Starting I/O

 DEVICE REQUIRED I/O INFORMATION

Disk

Operation CodeMemory Transfer AddressNumber of Bytes to TransferTrack AddressSector Address

 TapeOperation CodeMemory Transfer AddressNumber of Bytes to Transfer

 PrinterTerminalSerial Device

Operation Code (read/write)Character to Transfer

 Timer Time interval

Interrupt Servicing• The most complicated part of most I/O drivers or I/O supervisor modules is

the interrupt handler. • Much of the device control is embedded in the interrupt handler, which is

given control asynchronously when the device needs service. – This could involve processing the next character for a device in the case of a

non-DMA device, – starting a second or third phase of an I/O operation for DMA devices (for

example, a read after a seek to sector on some disks).• Information needed by the interrupt handler must be provided by the main

portion of the device driver. Such information is usually contained in the control blocks that represent the current I/O operation, just as PCBs represent process execution to the dispatcher.

– Device interrupt handlers must save all registers and hardware status of the interrupted program and restoring it before returning to the interrupted program.

– Certainly the most complex part of interrupt handler service is error recovery – Error recovery routines can be either resident or dynamically loaded when

needed, depending on operating system design and requirements.

Possible errors for devices

 DEVICE POSSIBLE ERRORS

Disk

Invalid Track, SectorWrong DensityPower UnsafeData error

 TapeData errorEnd of tape

 PrinterPaper outPaper jamOff Line

Sample Error HandlerERROR HANDLER:

/* initialize counter and flag */loop = 0;tape_error = TRUE;/* repeat entire process up to ten times */while ((loop < 10) && tape_error) {/* backspace and reread up to nine times */count = 0;while ((count < 9) && tape_error) {backspace recordread record againif (read is ok) tape_error = FALSE;else count = count + 1;}

/* if error still present, backup further */if (tape_error) {

/* backspace ten records */count = 0;while (count < 10) {backspace recordcount = count + 1;

}/* skip forward nine records */count = 0;while (count < 9) {

forward space recordcount = count + 1;

}/* try reading again */read recordif (read is ok) tape_error = FALSE;loop = loop + 1; /* prepare for retry */} /* repeat if necessary */

I/O completion

• Once the requested operation is finished, some cleanup must still occur– Setting the status of the process requesting

the operation– Clearing the device busy status, and disabling

interrupts– Search a device queue, for the next operation

Scheduling I/O

process1 process2 process3

I/O event 1

I/O event 3

I/O event 2

Device or I/O queue

Multiple I/O queues

Figure 10--23: A Single I/O Queue

Figure 10--24: Multiple I/O Queues

PCB 0

Priority 60

Running Process

Ready QIO_Active Q

IO_Init Q

PCB 9

Priority 32

PCB 8

Priority 40

PCB 5

Disk Read

PCB 4

Printer Write

PCB 3

Disk Write

PCB 2

Disk Read

PCB1

Printer Write

PRINTER_IOCB

PCB7 Address

ECB Address

DISK_IOCB

PCB6 Address

ECB Address

Modified figure 10-25

Running Process

Ready QIO_Active Q

IO_Init Q

PCB 8

Priority 40

PCB 6

Priority 42

PCB 5

Disk Read

PCB 4

Printer Write

PCB 3

Disk Write

PCB1

Printer Write

PRINTER_IOCB

PCB7 Address

ECB Address

DISK_IOCB

PCB2 Address

ECB Address

PCB 0

Priority 60

PCB 9

Priority32

Modified Figure 1--27

• IO_COMPLETE:

/* Cleanup after disk operation, switch waiting process to ready state */if (operation is complete) {Save context of current process in PCBInsert PCB in ReadyQSet Disk ECB for disk I/O just completedMove PCB address in Disk IOCB to ReadyQSet Disk IOCB to idle state}/* setup next disk operation, if any */Search IO_WaitQ for another disk requestif (disk request found) {Move PCB address of next disk I/O request to Disk IOCBMove DIsk ECB address to Disk IOCBStart requested disk I/O operation}Invoke dispatcher to dispatch next process

• Figure 10--26: Handling an I/O Request Complete Interrupt