Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Cooperating Device Drivers

IP.com Disclosure Number: IPCOM000105816D
Original Publication Date: 1993-Sep-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 2 page(s) / 101K

Publishing Venue

IBM

Related People

Sotomayor Jr, GG: AUTHOR

Abstract

Most device driver models allow for only one device driver to access a specific set of hardware. The problem is that there exists a set of hardware where it is convenient to have multiple device drivers accessing the same hardware.

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

Cooperating Device Drivers

      Most device driver models allow for only one device driver to
access a specific set of hardware.  The problem is that there exists
a set of hardware where it is convenient to have multiple device
drivers accessing the same hardware.

      In many cases this is currently solved by layering the device
drivers, that is, having one device driver use another device driver
to actually access the shared hardware.  The layering is such that
the common code is provided by the lowest layer(s).  However, this
requires that the need for this layering was anticipated when the
first device driver was written.  It also requires that any new
devices are sufficiently close to the original devices so that the
common code can actually be used.  Normally, the interfaces provided
by the common code are largely ad hoc and vary widely between
different sets of devices.

      For example, on the PS/2* a new device was engineered that,
from an electrical standpoint, appeared to be a diskette drive but in
actuality was a tape drive.  It required that the diskette controller
be pro- grammed in unusual ways in order for the drive to function
properly.  None of the diskette device drivers for the various
operating systems that run on the PS/2 had been structured to
anticipate a need such as this.  It required major changes to the
diskette device drivers to allow another device driver to acquire the
diskette controller and reprogram it.

Solution - The solution to the problem is to provide a general
mechanism that all device drivers must follow.  That mechanism is
described in the following paragraphs.

      A new entity is introduced called the Hardware Resource Manager
(HRM).  The HRM is responsible for identifying and managing all of
the hardware resources in a system.  A device driver gains access to
one or more hardware resources by requesting access to them from the
HRM.  It is important to note that except for identifying the
resources and granting access to them, the HRM does not play any
active role in the use of the resources.  However, the HRM may inform
the device driver that it must give up the hardware resource(s).
This occurs when there is another device driver that wishes to use
those resources.

      When a device driver is informed that it is to yield a set of
resources, it may respond to the HRM in one of several ways:

     a) Complete,
     b) Later, and
     c) Arbitrate

      When the HRM receives a Complete response from a device driver,
it assumes that the device driver has completed whatever actions were
necessary to place the resource(s) into a consistent state.  For some
resources, this may require no action on the part of the device
driver.  For others, the device driver may have to expend a fair
amount of effort.  Once the response is...