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