On Fri, Jun 03, 2011 at 07:33:58PM -0700, Nicholas A. Bellinger wrote: > > - what is the point of the transport_generic_process_write wrapper? > > Minus the stubbed WRITE overflow copy stuff, this primarly used by > tcm_loop to queue up the cmd's tasks for execution via > transport_execute_tasks() instead of a direct fabric module call.. > > Currently tcm_loop is the only user of this as we know the full WRITE > payload is available once the struct scsi_cmd as been dispatched via > ->queuecommand(). As a first step the stubbed out code really should go away ASAP, it's really rather confusing as it has little chance to work for the current code base. As a follow-on transport_generic_process_write should be replaced by a direct call to transport_execute_tasks, to make it more obvious what's going on here. If we then plan to keep the direct task execution from the submitter context we should document why we're doing that. One option would be to make ->write_pending return a boolean indicator whether we should call transport_exectute_tasks from transport_generic_write_pending/transport_generic_new_cmd, and thus making it more obvious that's it's actually similar to the read path in that respect. I'm still not convinced that running the read/write/flush/discard tasks from the caller is an all that good idea. They will 100% block for the file backend, and can block when we reach the request limit with iblock, and the blocking behaviour might differ for different kinds of requests. -- 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
