Boaz Harrosh wrote:
Vladislav Bolkhovitin wrote:
Christoph Hellwig wrote:
On Fri, May 02, 2008 at 05:53:22PM +0200, Bart Van Assche wrote:
Regarding scsi_execute_async(): I didn't know that this API is on its
way out. What will it be replaced by, and when ?
blk_execute_rq/blk_execute_rq_nowait plus the block level helpers built
ontop to build requests.
scsi_execute_async() is already a nice and simple helper function on top
blk_execute_rq_nowait(). What's the point then to remove it? Do you
consider that exposing scsi_execute_async() internals to its users is
better?
The problem with it is the use of sg list to *hack* in bio's. Which totally
ignores/duplicates block layer mechanisms. There is pending a large patchset
that removes the use of scsi_execute_async from sg/sr and friends to use blk_map_*
members and directly call blk_execute_*. The original patchset was written by
Mike Christie but is now brought up to date by Tomo. It should be submitted soon I think.
If you need good example of usage check out bsg.c it maps user-space data in all kind
of combinations. If you have kernel space memory it is even simpler.
Thanks for pointing on it. But it still remained unclear for me what's
the point in the scsi_execute_async() removal. Function
scsi_req_map_sg() looks pretty simple and straightforward, so I don't
see how the overall code can be simplified.
Bart.
---end quoted text---
If you need any help, please feel free to ask.
Boaz
--
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
