OS2DASD.DMD - Technical Reference

The OS2DASD Device Manager (OS2DASD.DMD) provides the interface between the OS/2 File Systems (FAT, HPFS) and Adapter Drivers (*.ADDs) that support fixed and removable magnetic disks.

This device manager allows the *.ADD drivers to communicate with adapter or disk hardware without interacting with the logical contents of these devices or being affected by the complexity of OS/2 block device driver interfaces. The device manager communicates with *.ADD drivers exclusively by way of Input/Output Request Blocks (IORBs), as described in the preceding chapters of the.

The primary functions of this device manager are:
 * 1) Implementing the OS/2 Kernel/FileSystem block device driver interfaces; creating IORBs as required for communication to .ADD drivers.
 * 2) Scanning .ADD drivers for removable or fixed magnetic devices.
 * 3) Managing partitioned devices by creating logical drives for partitioned disks and reporting these logical drives to the OS/2 kernel.
 * 4) Providing IOCtl interfaces to the file system utility applications to allow for the preparation of the media.
 * 5) Providing for the attachment from a set of logical drives to a physical removable device is called pseudo drive support. An example is the mapping of drive A: or B: to a single diskette drive.

Kernel/FileSystem Interfaces
The OS2DASD device manager supports three major types of kernel interfaces: Request Packets, Extended Disk Interface, and Generic IOCtls.

With the exception of Generic IOCtls, these interfaces are used by the OS/2 Kernel and OS/2 File Systems to communicate with device drivers and are not directly available to applications.

Request Packets
Request Packets are used for small I/O requests or status requests to the device manager.

The following table shows the Request Packets that are supported by the OS2DASD Device Manager:

The formats of these packets can be found in the OS/2 Physical Device Driver Reference. For more information regarding the implementation and interpretation of these packets by OS2DASD, see Request Packet Management.

Extended Disk Interface
The Extended Disk Interface provides a higher performance path for a limited set of commands.

The advantages of this interface are:
 * Multiple I/O requests may be submitted in a single list.
 * Each request may transfer data to or from discontinuous areas of memory.
 * Each request may specify a priority to other I/O requests.
 * A file system can directly call the device driver to submit I/O requests, rather than going through the OS/2 kernel.
 * This interface may be used at interrupt time.

See Request Lists and Request Control for information about the format of the Extended Disk Interface "Request Lists".

Generic IOCtls
IOCtl interfaces are generally used by the file system utility applications such as FORMAT and CHKDSK to prepare or access media when a file system is not operating. The interfaces also perform operations that query or change hardware-specific characteristics of a device.

Category 08h IOCtls apply to a single drive letter or partition. Most file system utility programs access disks using this IOCtl category.

Category 09h IOCtls apply to the entire physical device. In other words, these IOCtls ignore any partitioning scheme that may be present on the drive. Partitioning utility programs such as FDISK and FDISKPM use this IOCtl category to set up a disk partitioning scheme.

The OS2DASD Device Manager supports the IOCtls shown in the following table:

Block Device Management
When the OS2DASD initializes, it scans .ADD drivers for fixed or removable magnetic devices. For each device found, the driver creates an internal control block that is called a UnitCB.

To access the device, the UnitCB provides the linkage to the corresponding ADD driver and ADD UnitHandle.

When UnitCBs have been created, the driver creates VolCBs to represent each of the following:
 * Physical non-removable drive
 * Removable drive
 * Logical volumes on a partitioned drive

VolCBs are linked together to create a unit number ordering system, based on DOS conventions. In addition, VolCBs are linked to their corresponding UnitCB, which provides the information necessary to access the physical device by way of the ADD drivers.

Unit numbers are not equivalent to drive letters. The OS/2 Kernel/FileSystems assigns drive letters. For example, a block device driver cannot demand that a particular set of drive letters be assigned to it.

OS2DASD assigns unit numbers as follows: A VolCB is created for each non-removable drive found. This VolCB represents the drive as a single device and ignores any partitioning scheme. For each drive found, a unit number is assigned from 80h to 98h. Regardless of whether an .ADD driver is found claiming diskette units, Unit Numbers 0,1 will be declared. This prevents the traditional unit numbering from "shifting" on workstations with 0 or 1 diskette drives installed. There is an "implicit" assumption by OS/2 System Initialization, that OS2DASD will be the first block driver loaded. In addition, if a single diskette drive is installed, OS2DASD creates a pseudo drive B unit, which is mapped to the first diskette drive. OS2DASD scans the UnitCBs created previously for non-removable drives. The Sector 0 of each drive is read and the partition record is checked for a file system partition entry. See Boot Record Architecture for more information. If a file system partition is found, it is considered the primary partition on the volume. A VolCB is created and given the next available unit number from this range. When all non-removable drives have been scanned, sector 0 of each non-removable drive is read again and scanned for an extended volume entry. This entry points to a new extended boot sector on the same drive. The extended boot sector is read and scanned for a file system partition entry. If an entry is found, then a VolCB is allocated and assigned the next available unit number from this range. The sector is also searched for another extended volume entry. This process is repeated until the end of the extended volume chain on the drive is reached or no drive letters are left. When the search is completed, the same search is repeated on the next physical drive. After all non-removable drives have been processed and the primary or logical drives are allocated, then VolCBs are allocated for any remaining removable drives in the system.
 * 80h - 98h Physical Drives
 * 0,1 Reserved for diskette drives
 * 2-24 Logical Drives / Removable Devices

BIOS Parameter Block (BPB) Management
The BPB resides at byte 0 in the first sector of a file system partition. This sector is called the operating system startup record. On non-partitioned media, the BPB resides at sector 0, byte 0.

The operating system startup record does not contain a partition table. The partition containing the operating system startup record is pointed to by an entry at the partition table contained in a master or extended boot record.

The BPB is a shared data structure between a block device driver and the FAT file system. In the case of an HPFS, the driver maintains a pseudo BPB.

When the VolCB for the logical drive is created during OS2DASD initialization, the BPB for each logical drive is read.

Validation checks are made by OS2DASD on the BPB to determine if any BPB had been written to the media. In the absence of a valid BPB, OS2DASD creates one, based on the size of the partition. The remainder of the BPB fields are filled in by a table-driven lookup, based on the size of the volume. This BPB is supplied to the OS/2 Kernel and not written to the media.

The driver keeps two copies of the BPB. One representing the BPB determined from the media currently in the drive and one representing the device, assuming its maximum capacity.

For non-removable devices, the BPBs are always identical. For removable devices, the BPBs may differ if the media in the drive is formatted to a lower capacity than the drive is capable of handling.

An example would be a 720KB diskette in a 1.44MB diskette drive. The media BPB is altered to match the media when OS2DASD receives a Build BPB request packet. The device BPB is only altered by using the Category 08h, Function 43 "Set Device Parameters" IOCtl.

This would typically be done by FORMAT which forces a diskette drive to format media at a lower capacity than which it normally operates.

One other idiosyncrasy of BPBs is the Hidden Sector field. This is discussed further in the Request Packet Management section.

Request Packet Management
The following section groups request packets by function rather than by numerics.

Removable and Non-Removable Media
04h Read 08h Write 09h Write with Verify 18h Read (No caching) 19h Write (No caching) 1Ah Write with Verify (No caching)

These operations are relatively straightforward, except for the calculation of the location to read.

The disk location to access is calculated as follows:

Absolute Disk Location = Absolute location of Master/Extended Boot Record + Hidden Sector Field of Logical Drive BPB + RBA Offset in Request Packet

The no caching versions of these commands are handled identically to the regular versions except when commands 18h through 1Ah are processed. To suppress adapter level hardware caching, the appropriate bits are set in the EXECUTE_IO IORB.

Removable Media
01h Check Media Change 11h Reset Media Change 0Fh Check for Removable Media 12h Get Logical Drive Map 13h Set Logical Drive Map 01h Check Media Change 11h Reset Media Change

When a Check Media Change packet has been received and the last unit status indicates that a media change has not occurred, then OS2DASD will send a request to the .ADD driver to get an updated status. If the current internal status indicates the media has changed, then "Changed" status will be returned. OS2DASD retains the result of this call and monitors for a media change indication on other I/O operations. When a Media Change is detected, the driver retains this information and blocks subsequent I/O requests to the unit until a Reset Media Change packet is received.
 * 01h - Check Media Change, 11h - Reset Media Change:

When OS2DASD receives the Check for Removable Media request, it locates the appropriate VolCB that corresponds to the requested unit number. The VolCB points to the corresponding UnitCB that contains the UnitInfo obtained from the .ADD driver. The BUSY bit of the request packet is set accordingly.
 * 0Fh - Check for Removable Media:

OS/2 allows multiple drive letters to be assigned to the same removable device. This assignment occurs automatically for the B drive on a single diskette system and by way of the EXTDSKDD.SYS driver to create additional drive letter aliases for removable drives. Only one drive letter at a time may be assigned to a removable drive from a set of drive letters that might potentially be mapped to the drive. The binding of a specific unit number to a removable device is accomplished through the use of Set Logical Drive Map. When OS2DASD receives the Set Logical Drive Map request, it looks up the physical removable device that should be assigned to this drive letter. It then updates its tables to indicate that the requested unit number owns the removable device. When OS2DASD receives the Get Logical Drive Map request, it determines the physical drive associated with the unit number provided. OS2DASD then searches the VolCBs to determine which VolCB currently owns the removable device. This owning unit number is returned to the kernel. The unit numbers returned on both of these packets must be 1-based rather than zero-based. A zero unit number returned indicates that there are no alias drive letters that can be assigned to the removable device.
 * 12h - Get Logical Drive Map, 13h - Set Logical Drive Map:

Non-Removable (Partitionable) Media

 * 16h Get Partitionable Disk Count
 * 17h Map Unit Numbers to Physical Drive

The number of non-removable drives is returned.
 * 16h - Get Partitionable Disk Count:

The request packet unit field indicates a non-removable drive number that is zero-based. OS2DASD adds Function 80h and searches for VolCBs associated with that particular physical unit. A bit map of unit numbers associated with the physical drive is returned. The bit numbering scheme for the bit mask corresponds to 2**(unit number) in a ULONG field.
 * 17h - Map Unit Numbers to Physical Drive: