Intro(D3i2o)

Description

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:

• The most important function is that of a multiplexor, where it acts as an abstraction layer between the transport layer and the OSMs.

• It manages the startup of the IOPs. To this end, it has what is effectively a startup OSM implemented within it.

• It acts as a library of common functions that all OSMs need.

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 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:

BUSNUM

Set equal to the global IOP number.

BRDID

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

BRDBUSTYPE

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

BA_DEVCONFIG

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

OSM

References