Browse Prior Art Database

Replaceable Device Driver Error Handling Components

IP.com Disclosure Number: IPCOM000117684D
Original Publication Date: 1996-May-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 109K

Publishing Venue

IBM

Related People

Bolt, M: AUTHOR [+4]

Abstract

Disclosed is an architecture in which a stack of error recovery and reporting components is configured and associated with Input/Output (I/O) operations performed on hardware adapters and devices. Within a highly-modular arrangement of device driver components, an "error stack" of modules contains an arbitrary number of error handling components. Modules can be inserted and removed from the error handling stack without impacting other system components, such as adapter- and device-specific driver code.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Replaceable Device Driver Error Handling Components

      Disclosed is an architecture in which a stack of error recovery
and reporting components is configured and associated with
Input/Output (I/O) operations performed on hardware adapters and
devices.  Within a highly-modular arrangement of device driver
components, an "error stack" of modules contains an arbitrary number
of error handling components.  Modules can be inserted and removed
from the error handling  stack without impacting other system
components, such as adapter- and device-specific driver code.

      Conventionally, hardware and software errors, detected by
device drivers while performing I/O operations, are reported to
system error handling components.  Error recovery, such as re-trying
a failed operation, may also be performed.  The sophistication of
error handling depends on the system configuration, reflecting, for
example, a need for a robust server environment, a need for improved
performance on a desktop client, or a need to occupy a small memory
footprint in an embedded system.

      The presently-disclosed architecture provides configurable
error handling, with error handlers reporting errors to system error
logging and monitoring facilities and initiating re-trials of failed
operations as necessary.  Error stacks are configured separately for
adapter operations, device operations, and logical device operations
(i.e., I/O operations performed on behalf of particular clients).
Stack modules are shared among adapter, device, and logical device
components through a hierarchical inheritance mechanism.

      Thus, modules in an error reply stack may contain
system-generic code, device-generic code, or device-specific code.
For example, system-generic code is used to notify the system error
logger of the status of an I/O operation.  Device-specific code is
used to initiate the re-try of a failed I/O operation on a class of
devices, such as storage devices.  Device-generic code can map a
device error code to an operating-system-specific error code.

      The Figure is a diagram of an error reply stack configuration
including extensions to re-drive failed I/O, to map device-specific
I/O error codes, and to log errors.  This architecture is implemented
within a "Framework" device driver architecture that handles I/O
request preparation, queuing, and completion processing.  The
Framework includes three execution paths, called "stacks," to
implement these functions.  Modules executing in these stacks are
called "extensions."  The "message" stack contains extensions that
prepare the client's I/O reque...