All members in the request block are writable
by the peripheral driver
All other members must be set
before sending the request to
the host adapter driver.
Some members are not implemented for
some host adapter drivers.
The request block structure contains
information needed by a wide variety of host adapter drivers.
As an example,
the supported host adapter driver
does not support linked commands at present.
Thus the link_ptr and link_id members
are not accessed by the host adapter driver
supplied with your software.
Future support for the link command capability is possible;
set these members to 0 (zero)
to ensure that conflicts do not occur.
The members of the scsi_io_req structure can be grouped according to whether they are set by the peripheral driver or the host adapter driver, whether they are reserved, or used internally by the peripheral driver.
struct exten *ext_p;
req_typeis equal to SCSI_INFO, then this member is used to return special information from the adapter driver. (See the section below on the SCSI_INFO command for a full description.) Otherwise, this member is reserved and should be set to 0.
For scatter/gather operations, this is the total length in bytes of all the scatter/gather requests added together.
For scatter/gather operations, this is the address of an array of type long that contains the physical memory locations into which to transfer data. In other words, there are the kernel I/O buffers.
For scatter/gather operations, this is the offset into the disk media from which the scatter/gather request will start, in blocks.
union scsi_cdb scsi_cmd;
struct buf *rbuf;
struct scsi_io_req *req_forw;
req_typemember of the request block. All SCSI peripheral drivers must be coded to process these types of requests and all SCSI host adapter drivers must be coded to handle these types of requests. See the sample code on the AHDK CD-ROM disk for examples of both SCSI peripheral and SCSI host adapter drivers. Note that special coding is required to process scatter/gather requests.
The possible values of the
req_type member are:
members identify the target.
This command may be sent more than once for a given target.
hacmd member is set to the value
the adapter will return information
about any BIOS-compatibility
geometry that it supports.
ext_p member in the request block
must point to a struct exten
which will be filled in by the adapter.
The members are filled in as follows:
Note that these values need not have any relation to the actual physical geometry of the device. If an adapter does not have a BIOS-compatible geometry, it may return the actual values for these members as reported by the device.
If the operating system is to be able to boot from disks attached to this adapter, the BIOS and operating system must agree on the disk's geometry. The exact mechansm of agreement may vary. Some BIOSes (and corresponding drivers) use fixed geometries such as [64 heads, 32 sectors/track] or [255 heads, 63 sectors/track]. Others select between several fixed geometries according to the total capacity of the disk. The values may also come from other sources such as user preferences, configured in the BIOS setup. In this case, some mechanism specific to the driver and the BIOS is required to communicate those values.
The boot program can only access the first 1024 cylinders of a disk; that is approximately the first 1GB of a [64, 32] geometry or the first 7.8GB of a [255,63] geometry. For the device to multi-boot different operating system, it must use a geometry that provides large bootable areas.
The operating system is limited
to a total of 65535 cyliders per disk.
Disks up to 64GB can be accessed
under a [64, 32] geometry;
disks up to 502GB can be accessed
under a [255, 63] geometry;
Peripheral drivers should use the capacity of the target unit (from the READ CAPACITY SCSI command), and the number of heads and sectors per track to calculate the number of cylinders for the device. The host adapter only sends back heads and sectors; the SCSI peripheral driver must calculate the cylinders. Note that the number of blocks is zero-based, so you need to add 1 to the last block to get the correct
Peripheral drivers that are not interested in this information
should set the
to the value SCSI_NO_INFO
which is equal to ``FFh''.
Some adapter drivers in SCO UNIX System V Release 3.2
Operating System Version 2.0 and earlier
required that the
hacmd member be set to
indicate whether the target is a direct-access device or
a sequential-access device.
Direct-access (disk) devices were required to set
hacmd to SCSI_DISK_INFO,
and sequential-access (tape) devices were required
hacmd to SCSI_TAPE_INFO.
data_ptrmember must point to a struct scsi_ha_info which will be filled in by the adapter. The
data_lenmember should contain the size, in bytes, of the scsi_ha_info structure.
If the adapter driver receives a command with the req_type member set to a value other than the ones above, it should return the value -1 and take no other action.
scsi_cmd. For those releases, the following members of the scsi_io_req structure were reserved and set to 0:
The ODDI 4 (SCO OpenServer Release 5.0.4) Sdsk peripheral driver is changed to send
req_type = SCSI_INIT req_p->hacmd = SCSI_VER_INFOearly in its open(D2osdi) routine. This
hacmdis a -1. Some drivers are coded so that if they don't understand the
hacmdvalue, they may panic or fail.
To avoid this problem,
the driver should check for a
so it can then provide the version info.
This change was implemented so that
the Sdsk driver can do its own
read cap cmd
and pass that value to the HBA
when asking for the heads and sectors.
In earlier OSDI versions,
the Sdsk driver was asking for
disk heads and sectors from the HBA
and then doing it's own read capicty command
to figure out the disk geometry ( cylinders ).
This required the HBA vendor
to submit its own read capacity
so it could figure out the proper heads and sectors
if it changed with disk size.
The information is passed in an unused area of the
structure. If there
are non zero values there,
a driver can make use of them.
``Scatter/gather operations'' in HDK Technical Reference