Browse Prior Art Database

Method for Accessing Removable-Media Device Drivers

IP.com Disclosure Number: IPCOM000113636D
Original Publication Date: 1994-Sep-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 2 page(s) / 79K

Publishing Venue

IBM

Related People

Feriozi, DT: AUTHOR

Abstract

Disclosed is the addition of a character device driver header to a block device driver load file, for providing drive letter information to an application program requesting such information, even when media is not inserted into a drive associated with the block device driver.

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

Method for Accessing Removable-Media Device Drivers

      Disclosed is the addition of a character device driver header
to a block device driver load file, for providing drive letter
information to an application program requesting such information,
even when media is not inserted into a drive associated with the
block device driver.

      Device drivers generally fall into block and character
categories, with block device drivers controlling random-access mass
storage devices, such as diskette drives and fixed disks, while
character device drivers provide control for sequential-access
devices, such a printers and communication ports.  DOS and OS/2*
block devices are known by an assigned drive letter, while
sequential-access devices are known by a name unique to the system,
such as LPT1 or COM1.

      Application programs gain access to devices and to device
drivers through a handle returned from a file system open call using
the generally-known name of the device, such as "C:" or "LPT1."  For
character devices, the open call will always succeed, so the device
driver can be accessed unconditionally.  However, in the absence of
the feature described herein, the open call for block devices is
defined only if the media has been mounted, so block device drivers
with removable media cannot be accessed by software until the media
has been inserted into the drive.

      To resolve this dilemma, a character device driver header is
added to the block device driver load file.  From the system point of
view, this means that an extra device driver is loaded into the
system.  Since the extra device driver is a character device driver,
it is always accessible, even if the media for the corresponding
block device driver is not mounted.  The character device driver is
chained to the block device driver header, so that it will be loaded
after the block device driver.  If the block device driver fails to
load, so will the character device driver, since it echoes the break
address and load status of the block device driver.  This character
device driver can be considered to...