All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: James.Bottomley@HansenPartnership.com, jens.axboe@oracle.com,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH 2/3] block: unexport blk_rq_append_bio
Date: Wed, 11 Feb 2009 16:52:37 +0200	[thread overview]
Message-ID: <4992E635.9080903@panasas.com> (raw)
In-Reply-To: <20090211233206H.fujita.tomonori@lab.ntt.co.jp>

FUJITA Tomonori wrote:
> On Wed, 11 Feb 2009 11:15:53 +0200
> Boaz Harrosh <bharrosh@panasas.com> 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()

So for exofs (filesystem) and pNFS-objects layout driver (Also part of filesystem)
I currently need blk_rq_append_bio(), unless we want to do something new for
these people.

Thanks
Boaz

  reply	other threads:[~2009-02-11 14:52 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-13 16:23 [PATCH 0/3] remove scsi_req_map_sg FUJITA Tomonori
2008-12-13 16:23 ` [PATCH 1/3] " FUJITA Tomonori
2008-12-13 16:23   ` [PATCH 2/3] block: unexport blk_rq_append_bio FUJITA Tomonori
2008-12-13 16:23     ` [PATCH 3/3] block: unexport bio_add_pc_page FUJITA Tomonori
2009-02-10 17:43     ` [PATCH 2/3] block: unexport blk_rq_append_bio James Bottomley
2009-02-10 18:19       ` James Bottomley
2009-02-11  0:21         ` FUJITA Tomonori
2009-02-11  8:17         ` Boaz Harrosh
2009-02-11  8:19           ` Boaz Harrosh
2009-02-11  9:15           ` Boaz Harrosh
2009-02-11 14:32             ` FUJITA Tomonori
2009-02-11 14:52               ` Boaz Harrosh [this message]
2009-02-11 15:01                 ` FUJITA Tomonori
2009-02-11 15:07                   ` Boaz Harrosh
2009-02-11 15:21                     ` FUJITA Tomonori
2009-02-11 15:41                       ` Boaz Harrosh
2009-02-11 16:04                         ` FUJITA Tomonori
2009-02-11 16:30                           ` James Bottomley
2009-02-11 17:55                             ` Boaz Harrosh
2009-02-12  1:30                               ` FUJITA Tomonori
2009-02-12  8:24                                 ` Boaz Harrosh
2009-02-12  8:28                                   ` [RFD] blk_rq_map_pages new API Boaz Harrosh
2009-02-12  9:19                                     ` Boaz Harrosh
2009-02-12  9:50                                       ` FUJITA Tomonori
2009-02-12 10:20                                         ` FUJITA Tomonori
2009-02-12 11:34                                           ` Boaz Harrosh
2009-02-12  8:41                                   ` [PATCH 2/3] block: unexport blk_rq_append_bio FUJITA Tomonori
2009-02-12  9:14                                     ` Boaz Harrosh
2009-02-12  9:50                                       ` FUJITA Tomonori
2009-02-12 12:19                                         ` [PATCH] [RFC] block: Don't let blk_put_request leak BIOs Boaz Harrosh
2009-02-12 13:49                                           ` Boaz Harrosh
2009-02-12 13:56                                             ` Boaz Harrosh
2009-02-12 17:27                                               ` [PATCH 1/2] " Boaz Harrosh
2009-02-12 17:30                                                 ` [PATCH 2/2] [RFC] libosd: Don't let osd abuse block internals, now that it's fixed Boaz Harrosh
2009-02-12 14:48                               ` [PATCH 2/3] block: unexport blk_rq_append_bio James Bottomley
2009-02-12 16:51                                 ` Boaz Harrosh
2008-12-15  7:28 ` [PATCH 0/3] remove scsi_req_map_sg Jens Axboe
2008-12-18  8:14   ` FUJITA Tomonori

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=4992E635.9080903@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jens.axboe@oracle.com \
    --cc=linux-scsi@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.