I2O Initiative Management Overview

• Introduction
• I₂O Conceptual Overview
• How It Works
• The Message Layer
• The Operating System Services Module -- OSM
• The Hardware Device Module -- HDM
• System Environments
• Conclusion
• Acronym Glossary

Introduction The demand for device driver portability between operating systems and host platforms, combined with increasing requirements for intelligent, distributed I/O processing has led to the development of the Intelligent Input/Output, or I2O (pronounced eye-two-oh) specification. The basic objective of I2O is to provide an I/O device driver architecture that is independent of both the specific device being controlled and the host operating system. This is achieved by logically separating the portion of the driver that is responsible for managing the device from the specific implementation details for the operating system that it serves. By doing so, the part of the driver that manages the device becomes portable across multiple operating systems. I2O also acts to hide the nature of the communication between various mechanisms, and in doing 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, the I2O intelligent I/O architecture greatly improves I/O performance. I2O-compatible systems will be able to more efficiently deliver the I/O throughput required by a wide range of high bandwidth applications, such as networked video, groupware, and client/server processing. At the same time, I2O imposes no restrictions as to where the layered modules execute, providing support for single processor, multiprocessor, and clustered systems. While I2O provides a compelling alternative to traditional monolithic driver models, its intent is not to create an entirely new interface to replace the driver architectures currently in existence. Rather, the objective is to provide an open, standards-based approach, which is complementary to existing drivers, and provides a framework for the rapid development of a new generation of portable, intelligent I/O solutions. (See Figure 1)

I2O Conceptual Overview The I2O model provides an ideal environment for creating drivers that are portable across multiple operating systems and host platforms. I2O drivers are divided into two parts: the OS Services Module (OSM) which interfaces to the host operating system's interface; and the Hardware Device Module (HDM) that interfaces with the particular device, media or server that the driver must manage. These modules interface with each other through a communication system comprised of two layers: a Message Layer which sets up a communications session between two parties, and a Transport Layer which defines how the two parties will share information. Much like a standard communications protocol, the Message Layer resides on the Transport Layer. The I2O communication model, when combined with an execution environment and configuration interface, provides the HDM with a host independent interface. The modules are able to communicate without knowledge of the underlying bus architecture or system topology. Messages form a meta-language for the modules to communicate that is independent of the bus topology and host Operating System interfaces. Just as a networking protocol stack, such as TCP/IP, is able to isolate communicating parties for each other's specific implementation details, the I2O is able to provide device driver portability. (See Figure 2)

How It Works The communications model for the I2O architecture is a message passing system. The communication model is analogous to a connection oriented networking protocol or the OSI layered model, in which two parties interested in exchanging messages 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. Upon 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 just like any other device driver from the host operating system's perspective. (See Figure 3)

The Message Layer

There are three basic components in the Message Layer: the message handle, the Message Service Routine (MSR), and the message queue. The message handle is essentially the "address" of the MSR registered in the call. A message handle is returned for every call to the Message Layer. The message queue provides the link between the requester and the desired service.

When a driver request is made, a message is deposited in a message queue and an MSR is activated to process the request. Messages themselves are made up of two parts: a header and a payload, where the header describes the types of request along with the return address of the originator.

I₂O is based on a queue between the requester and the MSR. The requester and service module can reside either on separate execution environments, or on a single processor system. I₂O also defines a neutral memory format, which provides independence for the host operating system memory model.

By providing an open, standard and neutral format mechanism for communication between the service modules, the Message Layer is the foundation.

The Operating System Services Module -- OSM

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 I₂O Message Layer.

Developers can also create host OSMs that works with multiple HDMs. By implementing an OSM with a single message handle which services multiple queues from different service modules, a single OSM can send and service requests to/from multiple, different devices.

The Hardware Device Module -- HDM

The HDM itself is surrounded by the I₂O 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.

System Environments

Both the HDM and OSM interface to a basic I₂O API set. The execution environment for OSMs consists of the execution environment provided by the hosting operating system along with the basic I₂O API set. The host-based I₂O 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 I₂O 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 I₂O objective of allowing HDMs to run in multiple target execution environments.

Because I₂O 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. (See Figure 4)

figure 4

Conclusion

Acronym Glossary

MSR -- Message Service Routine -- A part of the Message Layer, the MSR is the primary entry point for servicing requests from both the OSM and HDM.

Legal Stuff © 1997 Intel Corporation