On Sun, 2007-03-04 at 10:21 -0600, Mike Christie wrote: > I think they get around this and other request settings that need > resetting by using scsi_execute_async. They will take the command, data > direction and buffer fields from the original scsi_cmnd, then pass those > on to scsi_ececute_async which would allocate a new request and then as > you know that new request gets sent to the scsi layer and looks like a > brand new request. So I misspoke above. It might be better to say they > are using it for routing what the other multipath layers would call > cloned commands. But actually, that's what I don't think they want to do. scsi_execute_async() will try to map the sg list. What they probably get is a fully set up SCSI command which needs to be cloned to a new device, so the request sg setup has already been done. So what you need to do is something like get a request for the new device, clone the relevant parameters, set the flags to REQ_DONTPREP and inject it into the correct queue. You probably also need to clone the scsi_cmnd as well. Finally you need to chain the completions of the old and new commands. This should avoid having to setup and re tear down the requests, while not using some kludgy mechanism like special commands. However, obviously, this is speculation about the operation of an unseen driver, which is not incredibly profitable ... James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
