Intro -- I2O kernel functions


The I2O subsystem within the kernel is layered and consists of three parts:

Operating system-specific module (OSM)
This is the top layer. The design of the I2O subsystem allows for multiple OSMs. Currently, OSMs for SCSI/block storage, LAN, and I2O subsystem configuration (the ``pass-through OSM'' or ptosm) have been written. More OSMs will be defined in Version 2.0 of the I2O Architecture Specification.

The OSM's upper interface is one of the kernel's standard interfaces. For example, the SCSI/block storage OSM interfaces to the sdi subsystem; the LAN and configuration OSMs interface to a STREAMS stack.

Message layer
This is the middle layer. There can only be one message layer in each system, and it has three distinct areas of functionality:

Transport layer
This is the bottom layer. The transport layer is the layer which actually communicates with the I/O processor (IOP) hardware. The design allows for multiple transports, however, the only transport mechanism defined at present is for the single-segment PCI bus.

Initialization sequence

The message layer is the first to run its initialization procedure. This does little more than set up its internal structures.

The drivers in the transport layer next run their initialization routines. They scan the Configuration Manager for entries that they can control. The entries are stored in the Resource Manager (resmgr) and are mapped to the correct driver name by the DCU (Device Configuration Utility) as for other devices. When a transport driver discovers a device in the Configuration Manager that it can control, it retrieves any data that it requires, it assigns a unique local number to the IOP, and it registers this number with the message layer. It makes no attempt to initialize the IOP. The message layer assigns a system-wide (global) unique number to the IOP, and maintains a mapping between the global number and the transport driver's locally assigned number.

The message layer attempts to initialize each IOP when the transport registers it. It marks the state of each one in its internal tables as it is determined. Thus all IOPs registered by the transport are in the message layer's internal tables, including those that are faulty or disabled. As the message layer initializes each IOP, it reads its Logical Configuration Table (LCT). For each unclaimed object that it finds, it creates a resmgr entry.

The message layer stores the global IOP number in the UNIT field of the resmgr. It attempts to match the entries registered by the transports against those in the configuration database. It uses the BA_CONFIG entry to track individual IOPs. In the currently defined PCI-based transport, it builds a unique entry based on the PCI bus number, slot number and function number of the IOP.

As the message layer parses the LCTs from the IOPs, it checks whether the configuration database already has an entry for each object that it discovers. It relies on the IOP number and the persistence of the target ID (``tid'') to identify each object uniquely. The IOP number and ``tid'' are used to create a BA_CONFIG entry for the object. The message layer must also delete any entries for objects which are in the Configuration Manager's database but not in the LCTs. The objects are created in the Configuration Manager with the bus type I2O.

The board ID (BRDID) of the objects is derived from the ``class'' type in the LCT. In this way, as new objects are defined by the I2O Architecture Specification, they will appear in the resmgr database without any additional effort, and they may be matched by the usual Drvmap file mechanism.

The message layer creates the following entries in the resmgr database for objects that it discovers:

Set equal to the global IOP number.

Set equal to the ``ClassID'' field from the LCT. This is used by the DCU to match OSMs to objects in the usual manner.

Set equal to the bus type I2O. This has a value of 0x80.

Set equal to a value derived from the global IOP number and the ``tid'' of the device in the LCT. This is a 32-bit value:

Bits 32-16
The global IOP number, LSB in bit 16, null-padded.

Bits 15-12
Version control number, currently 0.

Bits 11-0
The ``tid'' as found in the LCT.

Message up interface

The message layer presents the following interfaces to the OSM layer above it. This does not include any functions found in the ``library'' part of the message layer:



The OSMs start by calling cm_getnboard to determine how many objects exist which they can control. If any objects exist, the OSM will register them with the message layer. Registration gives the OSM access to the LCTs. Using the data from the Configuration Manager and the LCTs, the OSM sends claims out for each device.


OSMMsgDeRegister(D3i2o), OSMMsgFreeReqBuf(D3i2o), OSMMsgFreeRepBuf(D3i2o), OSMMsgGetInboundFrameSize(D3i2o), OSMMsgGetNumIops(D3i2o), OSMMsgGetOutboundFrameSize(D3i2o), OSMMsgIopToKey(D3i2o), OSMMsgIopValid(D3i2o), OSMMsgKeyToIop(D3i2o), OSMMsgMfaConvert(D3i2o), OSMMsgOpenCall(D3i2o), OSMMsgRegister(D3i2o), OSMMsgGetReqBuf(D3i2o), OSMMsgSend(D3i2o), OSMMsgSetInboundFrameSize(D3i2o)
19 June 2005
© 2005 The SCO Group, Inc. All rights reserved.
OpenServer 6 and UnixWare (SVR5) HDK - June 2005