Providing Open Architecture High Availability Solutions

or suspended and redirected upon removal. Explicit control of device drivers and their association

with hardware is required so systems integrators can create and enforce policies governing the

working of the system.

In a traditional system the hardware, control software (typically a device driver) is very tightly

associated with the hardware it controls. Understanding of (static) address and interrupt mapping

from a processor to a device most often has been the responsibility of the device driver writer.

9.4.1 Device Resources Abstraction

It is easier to support the hot-swap of I/O cards if device driver design can be uncoupled from the

topology of the system. A hot-swap aware driver can be simplified through isolation from address

and interrupt mapping and resource allocation. The OS may provide a device-resource-facility

between the device driver and the mechanisms for finding the device. This can be used to abstract

the specifics of device address and interrupt mapping, effectively removing them from the driver

and segregating them to a driver support system with its own API. Moreover, this device-resource-

facility can initialize the bridge chips and set some initial policies governing expansion areas on the

additional buses connected by the bridge chips.

9.4.2 Stateful Device Driver Model

In a system that does not support hot-swap or high availability, applications programs and systems

code must assume that hardware resources (devices) and the associated drivers are always in a

ready state. Adding the dynamic nature of hot-swap devices to a system not only adds complexity

to system software, but invalidates such static configuration assumptions at all levels. As good

device driver style dictates, such complexity is best isolated in the device driver and specific

interfaces, since many aspects of hot-swap functionality are device specific.

A driver model based upon open standards, like Linux/UNIX, provides a set of standard entry

points that are used to interact with a device at an application level.

A stateful device driver model not only conforms to this standard style I/O interface, but also

provides control interfaces to support the dynamic insertion and removal of devices through the use

of a role state machine. By using a state machine, the driver can be structured to induce the needed

state transition through the use of a recognized mechanism such as ioctl() (I/O control)

commands. This driver model allows some level of diagnostics to be run on the specific device

while the system continues to provide service.

In order to allow off-line testing of a device while the operating system remains in service. It is

necessary to have at least one device state, a diagnostic state, that allows for continued processing

of the management control interface (ioctl) while keeping the user access to the device stream in a

quiescent state.

9.5 Support of the Application Layer

The process model can be used to extend and control depend-upon relationships that may define

simple functional groupings and software fault domains.