|
|
I2O (Intelligent Input/Output) is an I/O device driver architecture that is independent of both the specific device being controlled and the host operating system. It supports a specialized hardware I/O processor (IOP) that makes a common interface available for each type of device on all platforms. This means that a single driver is required in the kernel for each class of device, instead of one driver platform.
The SCO implementation of the I2O architecture conforms to the specifications of the I2O Special Interest Group (SIG), of which SCO is a member. Further information is available at the I2O SIG homepage.
I2O logically separates the portion of the driver responsible for managing the device from the specific implementation details for the operating system that it serves. In this way, the part of the driver that manages the device becomes portable across multiple operating systems.
Similarly, I2O hides the nature of the communication between various mechanisms, and so provides processor and bus technology independence.
I2O is also designed to facilitate intelligent I/O subsystems, with support for message-passing between multiple independent processors. By relieving the host of interrupt intensive I/O tasks required by the various layers of a driver architecture, I2O greatly improves I/O performance.
The layered modules normally reside on the IOP.
I2O provides support for single processor, multiprocessor, and clustered systems.
I2O split drivers model
I2O drivers consist of two parts:
The modules communicate via a metalanguage that is independent of the bus topology and host operating system interfaces.
I2O message interface
The communications model is a message passing system, analogous to a connection oriented networking protocol or the OSI layered model, in which two parties utilize the Message Layer to set up a connection and exchange data and control.
When the OSM is presented with a request from the host operating system, it translates the request into an I2O message and dispatches it to the appropriate HDM for processing. On completion of the request, the HDM dispatches the result back to the OSM by sending a message through the I2O Message Layer. The OSM behaves like any other device driver from the host operating system's perspective.
I2O Software Architecture
The OSM provides the interface between the host operating system and the I2O Message Layer. In the split driver module, the OSM represents the portion of the driver that interfaces to specific Application Programming Interfaces (APIs) on the host, translating them to a neutral message-based format that is then sent to an HDM for processing.
The OSM translates requests from the host operating system into messages which can be dispatched to the appropriate HDM for processing. HDM information is forwarded back to host operating system through the OSM via the I2O Message Layer.
The HDM provides the device specific portion of the driver that understands how to interface with the particular controller and devices. HDMs are roughly analogous to the hardware-specific portion of the network and SCSI drivers. The HDM translation layer is unique to each individual hardware device and vendor, and supports a range of operation types, including synchronous, asynchronous request, event driven, and polled.
The HDM itself is surrounded by the I2O environment, which provides the necessary support for the operating system processes and bus independent execution. HDMs are typically written in C or C++ and can be architected in a manner which minimizes changes when moving from one hardware platform to another.
I2O is designed for single processor, multiprocessor, and clustered processor systems, as well as desktop, communications, and real-time system environments.
Both the HDM and OSM interface to a basic I2O API set. The execution environment for OSMs consists of the execution environment provided by the hosting operating system along with the basic I2O API set. The host-based I2O environment complements the operating system services by providing a bridge between the operating system device APIs and the HDM.
In order to accommodate access to real-time operating system environments, HDMs have an additional set of I2O Embedded Kernel Services APIs. This interface provides HDMs with access to required operating system functions, without exposing the actual Embedded Operating System's interfaces to the HDM. This layer provides the set of services needed to establish a cocoon that HDMs load into, thereby making them independent of their surrounding execution environment. This is especially important in meeting the I2O objective of allowing HDMs to run in multiple target execution environments.
Because I2O is designed to readily support single processor systems, the service layer is scalable. It can easily be simplified in scope for more restricted processing environments.