--- James Bottomley <James.Bottomley@xxxxxxxxxxxx> wrote: > 2) This scsi_req_abort_cmd() is fundamentally the wrong logic. > Everything else is communicated back as a result code from the command > in done(). This should be no different ... A status return of > DID_FAILED which scsi_decide_disposition() always translates to FAILED > would seem to do exactly what you want without all the overhead. You objected to this already, when I first posted the patch, but I didn't have time to explain: http://marc.theaimsgroup.com/?l=linux-scsi&m=113833937421677&w=2 Let me now explain, after your twice objecting in the same way to the patch: You CANNOT call the done() function on a command (and return DID_FAILED) because this terminates the nexus established when queuecommand() got called, and then later try to "recover" the command as you're suggesting here and in the thread I included the link to above. That is, when queuecommand() got called, the nexus is now with the driver, and/or the FW and/or the transport and/or the device, _depending_ on how far the driver/fw/transport/device got to executing the command. The only way to _terminate_ the command nexus with the driver is by calling done(), which means, "I (the driver) am completely done with this command, I'm not referencing it, nor will you hear about it any more, and I'm giving it back to you, SCSI Core." This is _basic_ SCSI knowledge. For this reason, "scsi_req_abort_cmd()" needs to exist. It causes recovery of the command to begin, in a universal way, independent of if the timeout and/or the eh had been differently defined. As well as, scsi_req_abort_cmd(), can be called by either SCSI Core or a driver, from any context, without worrying where the command is. Luben - : 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
