On Tue, Oct 02, 2012 at 12:24:26AM -0700, Nicholas A. Bellinger wrote: > For iscsi-target this ends up being overly complicated with the multiple > combinations of immediate data + unsolicited data-out in the existing > code paths. Andy mentioned doing this once before and I thought it > would end up adding too much complexity to target_submit_cmd() for the > benefit, but am still happy to be proved wrong here. ;) It seems like we could just delay the submission long enough to always be able to use target_submit_cmd, but I'll let Andy speak if he's deeper into this. One thing that really confuses me about iscsit is the use of transport_generic_new_cmd. The only additional code in transport_handle_cdb_direct are a few debug checks, setting of t_state and transport_state and a call to transport_generic_request_failure on errors. What part of this does iscsit_handle_scsi_cmd want to avoid? Why are the other callers fine with this additional work? -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
