Re: [PATCH 2/3] block: unexport blk_rq_append_bio

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



FUJITA Tomonori wrote:
> On Wed, 11 Feb 2009 16:52:37 +0200
> Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote:
> 
>> FUJITA Tomonori wrote:
>>> On Wed, 11 Feb 2009 11:15:53 +0200
>>> Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote:
>>>
>>>> I spoke too soon. There is one more place that uses blk_rq_append_bio, that is
>>>> the place that adds the read/write bio that is received in osd_req_write/read.
>>>> The reason I receive a bio at these is because mainly I need a way to
>>>> accept struct page* arrays, as well as kernel & user pointers. A bio is a nice
>>> The API using an array of pointers to page can handle everything. So
>>> why do the users of ULD (some rare file systems, I guess), osd
>>> initiator, need to build bios and pass them?
>>>
>>>
>>>> general carrier for any type of memory. Given a bio at hand there are no ways
>>>> left to prepare a request from it save the FS generic_make_request() route.
>>>>
>>>> I was thinking of using struct sg_iovec* at one stage but they look very
>>>> scary when used with page*, and mapping a page to a pointer but not doing
>>>> cache sync and all that jazz. A bio is a very nice carrier of a scatter-gather
>>>> list of memory. It has all the API for any needs. blk_rq_append_bio() was the last
>>>> way to associate a bio with a request. (except for privileged block-filesystems)
>>> We need to remove the usage of blk_rq_append_bio() in scsi.
>>>
>>>
>>>> So the first thing we have to decide is what API we need at read/write
>>>> today there is:
>>> You are talking about the API for osd file systems (or something
>>> related with osd), right? If so, I think that you can do whatever you
>>> want to do now. You can make a mistake since it's in-kernel API.
>>>
>>>
>>>> void osd_req_read(struct osd_request *or,
>>>> 	const struct osd_obj_id *, struct bio *data_in, u64 offset);
>>>>
>>>> in exofs I use these two:
>>>>
>>>> int osd_req_read_kern(struct osd_request *or,
>>>> 	const struct osd_obj_id *obj, u64 offset, void *buff, u64 len);
>>>> int osd_req_read_pages(struct osd_request *or,
>>>> 	const struct osd_obj_id *, u64 offset, u64 length,
>>>> 	struct page **pages, int page_count);
>>>>
>>> As I wrote above, if you have an interface handling 'struct page
>>> **pages', then there should be ok.
>> Sorry you miss understand me, I did not explain well.
>>
>> int osd_req_read_pages(,,,, struct page **pages, int page_count);
>>
>> Is in exofs.ko. It builds a bio out of **pages then calls
>> osd_req_read(,,bio,) which will then call blk_rq_append_bio()
> 
> As I wrote in the previous mail, why does exofs need to build a bio?
> Why can exofs pass pages to osd ULD?
> 
> 

Sure it can pass pages to ULD but then how ULD maks a request out of
pages? And it gets more complicated then that (above multiple times)

But lets try to solve just the pages first.

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux