From: Boaz Harrosh <bharrosh@panasas.com>
To: Vladislav Bolkhovitin <vst@vlnb.net>
Cc: Christoph Hellwig <hch@infradead.org>,
Bart Van Assche <bart.vanassche@gmail.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
linux-scsi@vger.kernel.org, scst-devel@lists.sourceforge.net,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: Re: [PATCH 2.6.25.1] Add scsi_execute_async_fifo()
Date: Tue, 13 May 2008 20:35:10 +0300 [thread overview]
Message-ID: <4829D14E.10909@panasas.com> (raw)
In-Reply-To: <4829C653.9050205@vlnb.net>
Vladislav Bolkhovitin wrote:
> 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.
>
Well No, scsi_req_map_sg() is a complete hack. If you have user memory
or kernel memory you better go through blk_map_* which will take care of
device masks, alignment and all, where here the ULD does that. So you have
2 places of waisted code both at ULD to build the SG right, and here to
translate SG to BIO. Where at block layer you have one function call.
Try it out you see that not using scsi_execute_async() is much more simple
at ULD then using it.
If you do mmap then Tomo has code for block layer to support that.
>>>>> Bart.
>>>> ---end quoted text---
>>>>
>> If you need any help, please feel free to ask.
>>
Boaz
next prev parent reply other threads:[~2008-05-13 17:36 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-02 14:38 [PATCH 2.6.25.1] Add scsi_execute_async_fifo() Bart Van Assche
2008-05-02 15:33 ` Christoph Hellwig
2008-05-02 15:53 ` Bart Van Assche
2008-05-02 15:55 ` Christoph Hellwig
2008-05-02 16:06 ` Bart Van Assche
2008-05-02 16:16 ` Matthew Wilcox
2008-05-02 16:23 ` Bart Van Assche
2008-05-02 16:30 ` James Bottomley
2008-05-02 16:43 ` Bart Van Assche
2008-05-02 16:49 ` Matthew Wilcox
2008-05-02 16:57 ` Bart Van Assche
2008-05-02 17:02 ` Matthew Wilcox
2008-05-02 18:21 ` Vladislav Bolkhovitin
2008-05-02 16:18 ` James Bottomley
2008-05-02 16:39 ` Bart Van Assche
2008-05-02 18:09 ` Vladislav Bolkhovitin
2008-05-02 18:17 ` SCSI target subsystem Vladislav Bolkhovitin
2008-05-03 9:41 ` Bart Van Assche
2008-05-03 9:53 ` Matthew Wilcox
2008-05-03 10:39 ` Bart Van Assche
2008-05-03 13:28 ` Matthew Wilcox
2008-05-03 14:48 ` Bart Van Assche
2008-05-04 15:53 ` Bart Van Assche
2008-05-04 11:35 ` Vladislav Bolkhovitin
2008-05-04 15:23 ` Vladislav Bolkhovitin
2008-05-04 11:48 ` [PATCH 2.6.25.1] Add scsi_execute_async_fifo() Vladislav Bolkhovitin
2008-05-04 17:53 ` Boaz Harrosh
2008-05-13 16:48 ` Vladislav Bolkhovitin
2008-05-13 17:35 ` Boaz Harrosh [this message]
2008-05-14 15:58 ` [Scst-devel] " Vladislav Bolkhovitin
2008-05-14 16:38 ` Boaz Harrosh
2008-05-14 16:49 ` Vladislav Bolkhovitin
2008-05-04 15:30 ` Bart Van Assche
2008-05-08 15:02 ` Bart Van Assche
2008-05-08 15:54 ` [Scst-devel] " Arne Redlich
2008-05-13 16:47 ` Vladislav Bolkhovitin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4829D14E.10909@panasas.com \
--to=bharrosh@panasas.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=bart.vanassche@gmail.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=scst-devel@lists.sourceforge.net \
--cc=vst@vlnb.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).