QIO
From Wikipedia, the free encyclopedia
QIO (Queue I/O) is a term used in several computer operating systems designed by the former Digital Equipment Corporation (DEC) of Maynard, Massachusetts.
I/O operations on these systems are initiated by issuing a QIO call to the kernel. The call returns immediately and if the I/O operation is successfully enqueued, it will be done asynchronously with its completion signaled by the raising of an event flag and possibly the issuance of an Asynchronous System Trap (AST) to the calling process/task.
Optionally, the call may be issued as QIOW (Queue I/O and Wait for completion), allowing synchronous I/O. In this case, the wait-for-event-flag operation will be done automatically and the call will not return until the I/O operation has been completed or has failed.
The following operating systems implemented QIO(W):
- RSX-11 (including all of the variants)
- RSTS/E (synchronous only, emulated by the RSX run-time system)
- VMS
Contents |
[edit] QIO arguments in VMS
Under VMS, the arguments to the QIO call are as follows:
- The number of the event flag to set when the operation completes. It isn't possible to not specify an event flag; flag 0 was a valid flag. It is perfectly permissible to have multiple operations going at once which would all set the same event flag on completion; it is then up to the application to sort out any confusion this might cause, or just ignore that event flag.
- The channel, a small integer previously assigned to the device on which the operation is to be performed. At this level, all operations on disk files and directories (filename parsing, directory lookup, file opening/closing) are done by appropriate QIO requests; the application always starts by assigning a channel to a device, in this case the appropriate disk device.
- The function code to be performed. 6 bits are assigned to the basic code (e.g. read, write), with a further 10 bits for "modifiers" whose meaning depend on the basic code.
- The optional address of the 8-byte I/O status block (IOSB) which is cleared by the QIO call, and filled in on completion of the I/O operation. The first two bytes always hold the completion status (e.g. success, end of file reached, timeout, I/O error etc), while the next two bytes normally return the number of bytes read or written in the operation. The meaning, if any, of the last four bytes is operation-dependent.
- The optional address of the AST routine to invoke when the operation completes.
- An additional parameter (whose meaning is up to the caller) to be passed to the AST routine.
- A partially-standardized list of up to six parameters known as P1 through P6. The first two parameters typically specify the I/O buffer starting address (P1), and the I/O bytecount (P2). The remaining parameters vary with the operation, and the particular device for which I/O is being enqueued. For example, for a computer terminal, P3 might be the time to allow for the read to complete whereas, for a disk drive, it might be the starting block number of the transfer.
[edit] QIO completion
There are three different ways to tell when the queued I/O operation has completed:
- When the event flag is set.
- When the first two bytes of the IOSB become nonzero (VMS uses odd integers for successful status codes, and even ones for failure codes, while zero is never a valid status code and could be used to indicate that the QIO was still in process).
- When the AST routine is executed.
[edit] Unusual QIOs that require complex processing
Simple QIOs, such as read or write requests, are either serviced by the kernel itself or by device drivers. Certain more complicated requests, specifically those to do with tape drives and file-level operations, are executed by an Ancillary Control Processor (ACP) (a special purpose task with its own address mapping). At one time the Files-11 file system was provided by a process called F11ACP and the Files-11 Structure Level 2 file system was provided by F11BACP. The functionality of the latter process was later moved into the kernel in order to save the overhead of process context switches and is now called an XQP (eXtended Qio Processor).
[edit] IO$_READPROMPT
Probably the most complex single QIO request possible is the VMS terminal driver's IO$_READPROMPT call with the IO$M_TIMED modifier; this version of this QIO required the use of all six parameters, using them as follows:
- P1 is the address of the buffer into which the input characters were read
- P2 is the length of the buffer, limiting the maximum number of characters to read. If the buffer is filled, the read will complete successfully, even if the user does not type a line-terminator character. Zero is allowed, in which case the read will terminate successfully with zero characters read.
- P3 is the maximum number of seconds to wait for more input. This is only used if the IO$M_TIMED modifier is present, and a value of zero means zero seconds: the read will terminate immediately, so the only possible input will be whatever had been "typed ahead" by the user.
- P4 is the address of the optional "terminator mask", specifying which input ASCII characters will be construed as terminating the read. If omitted, this defaults to the usual VMS line delimiters including carriage-return (but not line-feed). It is possible to specify a mask with no line terminators, in which case the read will only complete when the buffer is full, or the timeout has elapsed.
- P5 is the address of a prompt string to be displayed to the user before accepting input. The value of providing this prompt as part of the read operation, instead of as a separate prior write operation, is that it will be automatically redisplayed in any situation requiring a refresh of the input line while the read is still in progress (such as after an operator message has been broadcast to the terminal, or the user hits CTRL/R to redisplay the line).
- P6 is the length of the prompt string.
By appropriate choices of the above parameters, it is possible to do both terminal input and output with the one call, there is no need to use the regular IO$_WRITEVBLK call for terminal output at all.