[stgt] [PATCH] [tgt]: Convert bs_sg to use BSG v4 interface

[Alexander Nezhinsky]

> I can't recall the discussion, but the new implementation passes
> though all the commands. So it can inform initiators of the cache mode
> properly and pass SYNC commands to the underlying devices properly.

Here is one passage from an old mail:

> I made it clear, SCSI passthrough is not an option. So any command
> filtering (that's exactly passthrough, as I wrote in the previous
> mail) is not an option too.

> If you let some SCSI commands (maybe you want to let MODE SELECT pass
> too to change WCE), you need to track the state of scsi devices
> (passed commands could change the state). It opens up a whole new can
> of worms. For example, you need to make sure that unit attention that
> tgtd fakes are consistent with the real state of scsi devices."

I found the new patches for the passthrough support, that i missed in 
the recent posts. There are plenty of discussions on technical details
regarding callbacks, api design etc., but could you explain in a few words
how the above-mentioned problem of device state maintenance is solved?
(just to make the reading the new code easier).

> Nick, do you still want this patch? I guess that you prefer sg now
> since bsg doesn't support iovec.

But the present code does not use multiple buffers to necessitate iovec.

>> I have read the kernel module's source, and it looks that it depends on
>> support for executing scsi commands in some layers below, 
>> within the block subsystem.

>bsg doesn't expect a device to support SCSI commands. You can create
>bsg devices for non SCSI devices.

This sounds great! 
What i could not understand was, which entity would emulate scsi commands
when it sees this "scsi cmd" request type: 
  rq->cmd_type = REQ_TYPE_BLOCK_PC;

--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html