Kernel Extensions and Device Support Programming Concepts

A Typical Initiator-Mode FCP and iSCSI Driver Transaction Sequence

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

1. The 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 or the LUN to internal tables for configuration purposes, and validating the request size.
3. Although the 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 adapter device driver fills in the scsi_buf status_validity field, updating the scsi_status and adapter_status fields as required. The 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 adapter driver and autosense data is returned from the 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 device driver dd_iodone entry point, signaling the device driver that the particular transaction has completed.
5. The 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 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.