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

[FUJITA Tomonori]

On Tue, 15 Jun 2010 18:43:45 +0300
"Alexander Nezhinsky" <alexandern at voltaire.com> wrote:

> > 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).

The old code uses sg for _only_ WRITE_* and READ_* commands. In the
above example, MODE SELECT isn't passed to the underlying device. So
tgt's emulated device state can be different from the state of the
underlying device.

The new code passes all the commands to the underlying device
(i.e. MODE SELECT, whatever). Such doesn't work in some cases
(e.g. REPORT_LUNS might return the wrong info) however the new code
doesn't have the above problem.


> > 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.

Yeah. But I thought that he wants to change it for iovec. I'm not
sure.


> >> 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;

REQ_TYPE_BLOCK_PC doesn't mean SCSI commands. You can use it for
anything.
--
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