Installation of OS/2, DASD, SCSI, and CD-ROM Device Drivers

From EDM2
Jump to: navigation, search
Storage Device Driver Reference
  1. About This Book
  2. Introduction to DASD, SCSI, and CD-ROM Programming Interfaces
  3. Installation of OS/2, DASD, SCSI, and CD-ROM Device Drivers
  4. Adapter Device Driver Development Considerations
  5. DASD, SCSI, and CD-ROM Device Manager Interface Specification
  6. Error Handling
  7. Adapter Device Driver Command-Line Parameters
  8. DASD IOCtl Device Driver Test Tool
  9. Optical IOCtl Device Driver Test Tool
  10. Using Filter Device Drivers
  11. Library and Services
  12. CD-ROM Device Manager Interface Specification
  13. CD-ROM Device Driver Test Tool
  14. Building an OS/2 Virtual Disk Driver
  15. OS2DASD.DMD - Technical Reference
  16. Boot Record Architecture
  17. Extended Device Driver Interface Specification
  18. I/O Request Block - C Definitions
  19. OS/2 SCSI Device Driver Interface Specification
  20. Advanced SCSI Programming Interface (ASPI) OS/2 Specification
  21. Adapter Device Driver Interface Questions and Answers
  22. Device Driver Test Tool (DDTT)
  23. Glossary

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

The key design points of this OEM DASD, SCSI, and CD-ROM device support package include:

  • The ability to install and, subsequently, start up from a DASD device that requires an OEM-specific adapter device driver interface
  • An installation process that is transparent to the end-user (that is, it requires no interaction on the part of the end-user)

This chapter describes the strategy developed to address these design points and the responsibilities of a device driver supplier in order to participate in this strategy.

Using the BASEDEV Keyword

A base device driver performs I/O during the OS/2 kernel initial load sequence. There are a number of operational differences between base device drivers and installable device drivers. See Adapter Device Driver Development Considerations for a description of how this affects adapter device driver development.

The BASEDEV keyword new with the OS/2 2.0 operating system, loads a base device driver into the operating system. Its syntax is as follows:

    BASEDEV= ---- filename ---------------------|
                             \-- arguments --/

Unlike the DEVICE= statement, the BASEDEV= statement must not contain either drive or path information. The root directory of the startup partition is searched first for the specified file name, followed by the \OS2 directory of the startup partition. (In the startup sequence, the OS/2 operating system cannot process drive or path information at the point where BASEDEV= statements are processed. If drive or path information is included there, an error is generated.)

Also, unlike the DEVICE= statement, the file-name extension of the file being loaded has a special meaning. BASEDEV= statements are not necessarily processed in the order in which they appear in your CONFIG.SYS file. The extension of each BASEDEV= file name is examined; then, BASEDEV= statements are processed in the order indicated by the following figure.

(BASEDEV= Load Ordering by File Extension)
 .SYS (processed first)
 .VSD         |
 .TSD         |
 .ADD         |
 .DMD  (processed last)

Files with other file-name extensions are not loaded.

If several BASEDEV= statements load file names with the same extension, those files are loaded in the order in which they are encountered in the CONFIG.SYS file.

OS/2 System Installation

When the OS/2 operating system is first loaded from the installation diskettes, the following adapter device drivers and device managers are loaded:

Adapter Device Driver Supported Device Managers
IBM1FLPY.ADD ISA removable media driver
IBM1S506.ADD ISA ST-506 driver
IBM2FLPY.ADD ABIOS removable media driver
IBMINT13.I13 Generic INT 13h driver

Additional drivers supporting other OEM interfaces also can be present.

When each device driver initializes, it attempts to determine whether its target hardware adapter is present. If the hardware interface is recognized, the driver completes its initialization and, subsequently, is ready to manage I/O operations during OS/2 system installation. If the hardware interface is not recognized, the device driver will fail the initialization with the Quiet Fail flags set. Quiet failure prevents the generation of failure messages on the workstation display.

Hardware interfaces that are not recognized by any of the drivers on the OS /2 initialization diskette are driven by the generic INT 13h adapter device (IBMINT13.I13) during installation. The IBMINT13 driver determines whether the previously loaded adapter device drivers have claimed at least as many fixed disks as indicated by the BIOS fixed disk count (0:475). The IBMINT13 driver will attempt to manage the remaining fixed disks. Consequently, to install and initially load the OS/2 operating system from an OEM adapter, it is important for the OEM to ensure that the IBMINT13 adapter device driver works properly with the OEM's adapter BIOS.

The OS/2 operating system can be installed and loaded on drives with BIOS IDs hex 80 or higher, provided that the OEM BIOS supplies INT 13h support for these drives.

OEM Adapter Device Driver Installation

OEM adapter device drivers are installed within the framework of the OS/2 DDINSTAL utility. The driver developer is responsible for supplying two modules (in addition to the adapter device driver) used by DDINSTAL - an adapter presence-check function and a device driver profile. DDINSTAL uses these modules to automatically detect the presence of OEM hardware interfaces and to install the corresponding drivers without user intervention.

Presence-Check Function

A presence-check function is a Ring 3 (nonprivileged) EXE program that determines whether a given hardware interface is present on a workstation. The module returns 0 when the specific interface is detected and 1 when the interface is not detected. For these modules to identify installed OEM adapters, Ring 0 services are provided by the device driver TESTCFG.SYS. TESTCFG provides the following IOCtl services for OEM adapter presence-check modules:

  • Determines CPU host bus type
  • Reads adapter ROM space
  • Executes IN/OUT instruction
  • Reads EISA adapter IDs

Refer to the OS/2 Physical Device Driver Reference for details on the TESTCFG device driver services.

Note: Be sure to write adapter presence-check modules to avoid disruption or conflicts with other installed host adapters.

Device Driver Profiles

A device driver profile is a file with a DDP extension containing a script that is interpreted by the OS/2 DDINSTAL utility. The device driver profile defines which files to copy from the installation diskettes to the target directories and specifies how the CONFIG.SYS file will be updated.

Refer to the Physical Device Driver Reference for specification of the DDINSTAL utility and the device driver profile language.

The DDINSTAL utility has been extended to support execution of the presence-check function and to conditionally process the DDP file, based on the return code from the presence check. To enable this support, the DDINSTAL utility now interprets the PRESENCECHECK keyword.

To use this new DDINSTAL feature, create a DDP file for the installation of your adapter driver, using the existing TITLE, CONFIG, and FILES keywords. Then, add a line to the DDP of the form:


where <filename> is the name of the presence-check function.

When the DDP is interpreted by DDINSTAL, that utility first scans the DDP for the PRESENCECHECK keyword. If the keyword is found, the corresponding EXE module is executed. Then, the entire DDP file is either processed or ignored, based on the outcome of the presence-check function.

A device driver profile for a hypothetical OEM-323x SCSI adapter could look like the following example. The file name would be OEM323x.DDP and the contents would be as follows:

*                                                                 *
* This is a device driver profile for a SCSI adapter.             *
* DDINSTAL would use this profile to automatically install the    *
* target device support.  The complete profile is processed only  *
* when the OEM323x.EXE program returns 0, indicating that the     *
* OEM-323x adapter is actually installed in the workstation.      *
*                                                                 *

 :PRESENCECHECK        * Check for the presence of an OEM-323x.
 OEM323x.EXE           * This might query POS IDs using TESTCFG.

  * The remainder of this file is processed only if         *
  * OEM323x.EXE indicates detection of the OEM-323x adapter.*

 Device driver profile for the OemTec OEM-323x OS/2 2.0 Adapter Device

 :CONFIG               * Add this line to CONFIG.SYS

 OEM323x.ADD \OS2\OEM323x.ADD
                       * Move this file from the installation
                       * diskette to the \OS2 directory on the
                       * target partition.

Processing Presence-Check Functions and DDP Files

OEM adapter device drivers that are packaged in the OS/2 product are installed near the end of the OS/2 system installation. At this point in the installation process, the DDP files for each OEM adapter device driver are evaluated by the DDINSTAL interpreter. This processing is completely automatic and transparent to the end user.

Use the same DDINSTAL framework for adapter device drivers that you distribute directly. Include the driver file, presence-check function, and DDP file on a reference diskette for the OEM adapter. The end user can install the adapter device support from the reference diskette, after the OS/2 operating system is loaded, by selecting Device Driver Install from the OS/2 System Setup folder. The installation of the device support will proceed automatically.