A Typical Initiator-Mode FCP Driver Transaction Sequence

A simplified sequence of events for a transaction between a FCP device driver and a FCP adapter device driver follows. In this sequence, routine names preceded by a dd_ are part of the FCP device driver, while those preceded by a scsi_ are part of the FCP adapter device driver.

1. The FCP device driver receives a call to its dd_strategy routine; any required internal queuing occurs in this routine. The dd_strategy entry point then triggers the operation by calling the dd_start entry point. The dd_start routine invokes the scsi_strategy entry point by calling the devstrategy kernel service with the relevant scsi_buf structure as a parameter.

2. The scsi_strategy entry point initially checks the scsi_buf structure for validity. These checks include validating the devno field, matching the SCSI ID/LUN to internal tables for configuration purposes, and validating the request size.

3. Although the FCP adapter device driver cannot reorder transactions, it does perform queue chaining. If no other transactions are pending for the requested device, the scsi_strategy routine immediately calls the scsi_start routine with the new transaction. If there are other transactions pending, the new transaction is added to the tail of the device chain.

4. At each interrupt, the scsi_intr interrupt handler verifies the current status. The FCP adapter device driver fills in the scsi_buf status_validity field, updating the scsi_status and adapter_status fields as required. The FCP adapter device driver also fills in the bufstruct.b_resid field with the number of bytes not transferred from the request. If all the data was transferred, the b_resid field is set to a value of 0. If the SCSI adapter driver is a FCP adapter driver and autosense data is returned from the FCP device, then the adapter driver will also fill in the adap_set_flags and autosense_buffer_ptr fields of the scsi_buf structure. When a transaction completes, the scsi_intr routine causes the scsi_buf entry to be removed from the device queue and calls the iodone kernel service, passing the just dequeued scsi_buf structure for the device as the parameter. The scsi_start routine is then called again to process the next transaction on the device queue. The iodone kernel service calls the FCP device driver dd_iodone entry point, signaling the FCP device driver that the particular transaction has completed.

5. The FCP device driver dd_iodone routine investigates the I/O completion codes in the scsi_buf status entries and performs error recovery, if required. If the operation completed correctly, the FCP device driver dequeues the original buffer structures. It calls the iodone kernel service with the original buffer pointers to notify the originator of the request.

Related Information

FCP Subsystem Overview

Required FCP Adapter Device Driver ioctl Commands

Understanding the Execution of Initiator I/O Requests

FCP Error Recovery

Understanding the scsi_buf Structure