Application I/O Interface

Application I/O Interface

* User application access to a many types of different devices is accomplished through layering, and through encapsulating all of the device-specific code into device drivers, while application layers are gives with a common interface for all ( or at least large general categories of ) devices.

* Devices differ on many different dimensions, as outlined in Figure below:

* Most devices can be grouped as either block I/O, character I/O, memory mapped file access, or network sockets. A few devices are unusual, such as time-of-day clock and the system timer.

* Most OSes also have an escape, or back door, which permits applications to send

commands directly to device drivers if needed. In UNIX this is the ioctl( ) system call ( I/O Control ). Ioctl( ) takes three arguments - The file descriptor for the device driver being processed, an integer indicating the desired function to be performed, and an address used for communicating or transferring additional information.

Block and Character Devices

* Block devices are processed a block at a time, and are indicated by a "b" as the first

character in a long listing on UNIX systems. Operations supported adds read(), write( ), and seek( ).

• Accessing blocks on a hard drive directly ( without going by the file system

structure ) is called raw I/O, and can speed up specific operations by bypassing the

buffering and locking normally conducted by the OS. ( It then becomes the application's responsibility to control those issues. )

• A new alternative is direct I/O, which uses the normal file system access, but

which disables buffering and locking operations.

* Memory-mapped file I/O can be layered on high of block-device drivers.

• Other than reading in the entire file, it is mapped to a range of memory addresses, and then paged into memory as needed using the virtual memory system.

• Access to the file is then finished through normal memory accesses, rather

than through write( ) and read( ) system calls. This approach is commonly used

for executable program code.

* Character devices are implemented one byte at a time, and are indicated by a "c" in UNIX long listings. Supported operations include get( ) and put( ), with more advanced functionality such as reading an whole line supported by higher-level library routines.

Network Devices

* Because network process is inherently different from local disk access, most systems provide a separate interface for network devices.

* One common and famous interface is the socket interface, which acts like a cable or pipeline connecting two networked entities. Data can be put into the socket at one terminal, and read out sequentially at the other terminal. Sockets are generally full-duplex, allowing for bi-directional data transfer.

* The select( ) system call permits servers (or other applications ) to identify sockets which have data waiting, without having to poll all available sockets.

Clocks and Timers

* Three types of time services are commonly required in modern systems:

• Get the current time of day.

• Get the elapsed time ( system or wall clock ) since a before event.

• Set a timer to start event X at time T.

* Unfortunately time operations are not quality across all systems.

* A programmable interrupt timer, PIT can be used to start operations and to measure elapsed time. It can be set to start an interrupt at a specific future time, or to trigger interrupts periodically on a regular basis.

• The scheduler uses a PIT to start interrupts for ending time slices.

• The disk system may use a PIT to schedule timing maintenance cleanup, such as flushing buffers to disk.

• Networks use PIT to delete or repeat operations that are taking too long to

complete. I.e. resending packets if an acceptence is not received before the timer goes off.

• More timers than actually subsist can be simulated by maintaining an ordered list of timer events, and setting the physical timer to go off when the next scheduled

event should occur.

* On most systems the system clock is implemented by counting interrupts generated by the PIT. Unfortunately this is restricted in its resolution to the interrupt frequency of the PIT, and may be subject to some drift over time. An alternate approach is to provide direct access to a high frequency hardware counter, which provides much higher resolution and accuracy, but which does not support interrupts.

Blocking and Non-blocking I/O

* With blocking I/O a process is transfer to the wait queue when an I/O request is made, and moved back to the ready queue when the request completes, allowing other processes to run in the meantime.

* With non-blocking I/O the I/O request returns suddenly, whether the requested I/O operation has ( completely ) occurred or not. This permits the process to check for available data without getting hung completely if it is not there.

* One method for programmers to implement non-blocking I/O is to have a multi-threaded application, in which one thread makes blocking I/O calls ( say to read a keyboard or mouse ), while other threads continue to modify the screen or perform other tasks.

* A subtle difference of the non-blocking I/O is the asynchronous I/O, in which the I/O request returns immediately allowing the process to continue on with other tasks, and then the process is notified ( via changing a process variable, or a software interrupt, or a callback function ) when the I/O operation has completed and the data is available for use. ( The regular non-blocking I/O returns suddenly with whatever results are available, but does not complete the operation and notify the process later. )