Skip to content
  • Boaz Harrosh's avatar
    [SCSI] bidirectional command support · 6f9a35e2
    Boaz Harrosh authored
    
    
    At the block level bidi request uses req->next_rq pointer for a second
    bidi_read request.
    At Scsi-midlayer a second scsi_data_buffer structure is used for the
    bidi_read part. This bidi scsi_data_buffer is put on
    request->next_rq->special. Struct scsi_cmnd is not changed.
    
    - Define scsi_bidi_cmnd() to return true if it is a bidi request and a
      second sgtable was allocated.
    
    - Define scsi_in()/scsi_out() to return the in or out scsi_data_buffer
      from this command This API is to isolate users from the mechanics of
      bidi.
    
    - Define scsi_end_bidi_request() to do what scsi_end_request() does but
      for a bidi request. This is necessary because bidi commands are a bit
      tricky here. (See comments in body)
    
    - scsi_release_buffers() will also release the bidi_read scsi_data_buffer
    
    - scsi_io_completion() on bidi commands will now call
      scsi_end_bidi_request() and return.
    
    - The previous work done in scsi_init_io() is now done in a new
      scsi_init_sgtable() (which is 99% identical to old scsi_init_io())
      The new scsi_init_io() will call the above twice if needed also for
      the bidi_read command. Only at this point is a command bidi.
    
    - In scsi_error.c at scsi_eh_prep/restore_cmnd() make sure bidi-lld is not
      confused by a get-sense command that looks like bidi. This is done
      by puting NULL at request->next_rq, and restoring.
    
    [jejb: update to sg_table and resolve conflicts
    also update to blk-end-request and resolve conflicts]
    
    Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
    6f9a35e2