Browse Prior Art Database

Diagnostic Kernel Extension

IP.com Disclosure Number: IPCOM000110006D
Original Publication Date: 1992-Oct-01
Included in the Prior Art Database: 2005-Mar-25
Document File: 2 page(s) / 80K

Publishing Venue

IBM

Related People

Mazzurana, PD: AUTHOR [+3]

Abstract

This article describes a method for implementing system diagnostics in a UNIX* environment that results in reduced development cycle time for device drivers, improved diagnostic capabilities, and reduced customer memory consumption.

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

Diagnostic Kernel Extension

       This article describes a method for implementing system
diagnostics in a UNIX* environment that results in reduced
development cycle time for device drivers, improved diagnostic
capabilities, and reduced customer memory consumption.

      In computer systems there is the need to be able to perform
various tests to diagnose possible hardware problems.  Such tests are
often referred to as system diagnostics, through which software
attempts to exercise hardware in anticipation of revealing failing
hardware.  The problems introduced by this need include increased
development time and increased complexity of "normal" operation
software.

      Traditionally in a UNIX environment, in order to provide access
to hardware (devices), a device driver specific to a given device is
required that understands the addressability and function of that
device.  Therefore, device drivers are the logical place to couple
needed diagnostic support in order to exercise specific hardware.
This results in several problems:
1) Every device driver must implement diagnostic-specific code.  This
alone results in increased development time due to the requirements
for the device driver to support diagnostics in addition to normal
function.
2) The code necessary to diagnose each piece of hardware remains
resident in the memory even during normal system operation.
3) The coupling of diagnostics and normal function code results in
extended code path lengths resulting in poorer normal operation
performance.
 4) Relying on the device driver for diagnostic functionality results
in limited diagnostic capability and a dependency on the software
organization in order to test the function of a device.

      The disclosed solution extends the normal functionality of the
UNIX kernel.  This can be done in a traditional UNIX environment
through additional kernel services or a pseudo device driver (driver
that is not mapped to any one physical device).  In an AI...