One of the major difficulties in trying to form an Input Output System is that there are so many different types of devices a computer is expected to communicate with. Some give input, some output, others both. Printers can run out of paper, users use different languages, the list is truly extensive. In an attempt to form a single uniform method of communication between the computer and these devices, the following technique is performed by a combination of the three following components: 1) Input Output Request Block 2) Device Descriptor 3) Device Request Queue First I shall describe the information held within the IORB and then I shall discuss its relationship with the Device Descriptor and the Device Request Queue. An IO Request Block is a data structure which holds the details about a single request to use an IO device. It passes it's contents between the device independent layers and device dependent layers.
Each IORB contains seven parameters: 1) Destination 2) Quantity 3) Mode 4) Originating process 5) Semaphore request serviced 6) Error location 7) Link to next IORB
The Destination states either: a) The location post-transfer (if any) b) The source location pre-transfer (if any) The Quantity states the amount of data to be transferred, if any. The Mode describes the task required of the IO device. Examples include requesting a tape drive to rewind, data transfer between two hard drives, the inputting of a keyboard press, or a character being sent for display on an monitor. In the last two examples it is the responsibility of the IO system to recognise the character code in use (such as the 256 character, 8 bit ASCII or the 65K character, 2 byte Unicode). Translation of this code into the standard Internal Character Code takes place immediately on input and immediately before output so as to allow everything apart from the devices connected with peripheral handling to use the standard internal character code. A translation mechanism is used to perform the conversion, normally in the form of a table or a program.
Originating Process is a pointer which contains the identity of the process which requested use of the IO device. Semaphore Request Serviced is a pointer to the location of the semaphore used for synchronising with the requesting process. It is this semaphore which will be set once the IO operation is complete. Error Location is also a pointer, to a location in memory where an error code will be stored should the requested IO operation be unsuccessful.
Link to next IORB points to other IORBs held within the Device Request Queue (see below).
Device Descriptor: In an attempt to protect device handlers from having to deal with each and every devices different characteristics, devices have a Device Descriptor associated with them. This Device Descriptor confines the characteristics of the device unto it'self and allows device handlers to form a similar approach to all devices. The device descriptor stores the following pieces of information; 1) The device information 2) The instructions to operate the device 3) Pointers to character translation tables/programs 4) The current status of the device (busy, available, broken) 5) The current user process (a pointer to the process descriptor of any process using the device) Every device in the system has it's own device descriptor, allowing the device handlers a uniform way of dealing with them. Each of the descriptors are placed into a linked list, which as a whole forms a Device Structure, pointed to from the central table.
Device Request Queue: So once the IORB has been created, it is then added to the Device Request Queue. The DRQ holds all the IORBs (IO requests) for a particular device, whether from the same process, or in the case of a shared devices, from other processes as well. The DRQ is connected to the Device Descriptor and it is the role of the Device Handler to take responsibility for the handling of all the IO requests for a device, both when a request begins, and when the task is completed. So now we are able to see how the three components, the IORB, the Device Descriptor and the Device request Queue are formed, we must look at how they operate together. Fixing things in your computer is kind of like getting some help fixing things around the house, you sometimes need an expert, and just like some friends of mine at Humble Handyman Services in Texas who are experts in many types of home and estate repairs (they can even change light bulbs-and they won't charge an arm and a leg), we are experts who will gladly take on the complex repairs as well as the small repairs-tasks you might do yourself if you had the time or the training. Before this however, it is important to have an understanding of what a Stream is. A Stream is a line of communication along which travels the request made by the process upon the device sought. Streams nor the programmer make a direct reference to the device its self, IO is simply directed to the Stream, and it is the Operating System which links the stream to the particular device. The OS chooses the device based on information supplied by the user, and the OS then binds a stream to that device, then, whenever the programmer sends or receives data to/from that stream, they are in fact communicating with the device, through the stream. When this first occurs it is called 'opening the stream', and 'closing the stream' is either done pro-actively by the process, or by default when the process has completed. An example of Streams is in UNIX, which instead calls them Files. It is these 'files' (streams) that allow the confining of a device's characteristics as mentioned earlier. These 'files' in the case of a printer could have the name /dev/lp and any text copied to this 'file' (stream) would be sent to the printer. Copying from the 'file' (printer) though is not possible, as a printer cannot create input, just as nor could you ask a tape drive 'file' to rewind. Cases like these are dealt with by transferring control to secondary forms of operations.
So, the procedure of how the operating system processes a request for IO from a user process takes the following form: DOIO ( stream, mode, amount, destination, semaphore ) DOIO is the name of a system IO procedure. Stream is the identifying number of the stream/file along which communication will take place. Mode describes the type of operation to perform, such as input from a keyboard, or burn a CD. Amount is the amount of data to be transferred, if any. Destination is the location, or the source from where, or where to the transfer will take place. Semaphore is the location where the process complete signal should be sent. This DOIO procedure can be used by several process at once (concurrently for a single processor system). It is this which keeps track which streams are connected to which devices. It also checks that parameters passed are consistent with the device descriptors parameters, and if so initiates the processing of the request.