Sun Microsystems, Inc.
spacerspacer
spacer www.sun.com docs.sun.com |
spacer
black dot
 
 
  Previous   Contents   Next 
   
 
Chapter 14

SCSI Target Drivers

The Solaris DDI/DKI divides the software interface to SCSI devices into two major parts: target drivers and host bus adapter (HBA) drivers. Target refers to a driver for a device on a SCSI bus, such as a disk or a tape drive. Host bus adapter refers to the driver for the SCSI controller on the host machine. SCSA defines the interface between these two components. This chapter discusses target drivers only. See Chapter 15, SCSI Host Bus Adapter Drivers for information on host bus adapter drivers.


Note - The terms "host bus adapter" or "HBA" used in this manual are equivalent to the phrase "host adapter" defined in SCSI specifications.


This chapter provides information on the following subjects:

Introduction to Target Drivers

Target drivers can be either character or block device drivers, depending on the device. Drivers for tape drives are usually character device drivers, while disks are handled by block device drivers. This chapter describes how to write a SCSI target driver and discusses the additional requirements that SCSA places on block and character drivers for SCSI target devices.

The following reference documents provide supplemental information needed by the designers of target drivers and host bus adapter drivers.

Small Computer System Interface 2 (SCSI-2), ANSI/NCITS X3.131-1994, Global Engineering Documents, 1998. ISBN 1199002488.

The Basics of SCSI, Fourth Edition, ANCOT Corporation, 1998. ISBN 0963743988.

Also refer to the SCSI command specification for the target device, provided by the hardware vendor.

Sun Common SCSI Architecture Overview

The Sun Common SCSI Architecture (SCSA) is the Solaris DDI/DKI programming interface for the transmission of SCSI commands from a target driver to a host bus adapter driver. This interface is independent of the type of host bus adapter hardware, the platform, the processor architecture, and the SCSI command being transported across the interface.

By conforming to the SCSA, the target driver can pass any SCSI command to a target device without knowledge of the hardware implementation of the host bus adapter.

The SCSA conceptually separates building the SCSI command (by the target driver) from transporting the SCSI command and data across the SCSI bus. The architecture defines the software interface between high-level and low-level software components. The higher level software component consists of one or more SCSI target drivers, which translate I/O requests into SCSI commands appropriate for the peripheral device. Figure 14-1 illustrates the SCSI architecture.

Figure 14-1 SCSA Block Diagram

The lower-level software component consists of a SCSA interface layer and one or more host bus adapter drivers. The target driver is responsible for the generation of the proper SCSI commands required to execute the desired function and for processing the results.

General Flow of Control

Assuming no transport errors occur, the following steps describe the general flow of control for a read or write request.

  1. The target driver's read(9E) or write(9E) entry point is invoked. physio(9F) is used to lock down memory, prepare a buf structure, and call the strategy routine.

  2. The target driver's strategy(9E) routine checks the request and allocates a scsi_pkt(9S) using scsi_init_pkt(9F). The target driver initializes the packet and sets the SCSI command descriptor block (CDB) using the scsi_setup_cdb(9F) function. The target driver also specifies a timeout and provides a pointer to a callback function, which is called by the host bus adapter driver on completion of the command. The buf(9S) pointer should be saved in the SCSI packet's target-private space.

  3. The target driver submits the packet to the host bus adapter driver using scsi_transport(9F). The target driver is then free to accept other requests. The target driver should not access the packet while it is in transport. If either the host bus adapter driver or the target supports queueing, new requests can be submitted while the packet is in transport.

  4. As soon as the SCSI bus is free and the target not busy, the host bus adapter driver selects the target and passes the CDB. The target executes the command and performs the requested data transfers.

  5. After the target sends completion status and the command completes, the host bus adapter driver notifies the target driver by calling the completion function that was specified in the SCSI packet. At this time the host bus adapter driver is no longer responsible for the packet, and the target driver has regained ownership of the packet.

  6. The SCSI packet's completion routine analyzes the returned information and determines whether the SCSI operation was successful. If a failure has occurred, the target driver retries the command by calling scsi_transport(9F) again. If the host bus adapter driver does not support auto request sense, the target driver must submit a request sense packet to retrieve the sense data in the event of a check condition.

  7. If either the command was completed successfully or cannot be retried, the target driver calls scsi_destroy_pkt(9F), which synchronizes the data and frees the packet. If the target driver needs to access the data before freeing the packet, it calls scsi_sync_pkt(9F).

  8. Finally, the target driver notifies the application program that originally requested the read or write that the transaction is complete, either by returning from the read(9E) entry point in the driver (for a character device) or indirectly through biodone(9F).

SCSA allows the execution of many of such operations, both overlapped and queued, at various points in the process. The model places the management of system resources on the host bus adapter driver. The software interface enables the execution of target driver functions on host bus adapter drivers using SCSI bus adapters of varying degrees of sophistication.

SCSA Functions

SCSA defines functions to manage the allocation and freeing of resources, the sensing and setting of control states, and the transport of SCSI commands. These functions are listed in Table 14-1.

Table 14-1 Standard SCSA Functions

Function Name

Category

scsi_init_pkt(9F)

Resource management

scsi_sync_pkt(9F)

 

scsi_dmafree(9F)

 

scsi_destroy_pkt(9F)

 

scsi_alloc_consistent_buf(9F)

 

scsi_free_consistent_buf(9F)

 

scsi_transport(9F)

Command transport

scsi_ifgetcap(9F)

Transport information and control

scsi_ifsetcap(9F)

 

scsi_abort(9F)

Error handling

scsi_reset(9F)

 

scsi_poll(9F)

Polled I/O

scsi_probe(9F)

Probe functions

scsi_unprobe(9F)

 

scsi_setup_cdb(9F)

CDB initialization function


Note - If your driver needs to work with a SCSI-1 device, use the makecom(9F) function.


Hardware Configuration File

Because SCSI devices are not self-identifying, a hardware configuration file is required for a target driver (see driver.conf(4) and scsi(4) for details). A typical configuration file looks like this:

    name="xx" class="scsi" target=2 lun=0;

The system reads the file during autoconfiguration and uses the class property to identify the driver's possible parent. The system then attempts to attach the driver to any parent driver that is of class scsi. All host bus adapter drivers are of this class. Using the class property rather than the parent property enables the target driver to be attached to any host bus adapter driver that finds the expected device at the specified target and lun IDs. The target driver is responsible for verifying this in its probe(9E) routine.

 
 
 
  Previous   Contents   Next