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 17:41:35 +0200	[thread overview]
Message-ID: <4992F1AF.9060702@panasas.com> (raw)
In-Reply-To: <20090212002105A.fujita.tomonori@lab.ntt.co.jp>

FUJITA Tomonori wrote:
> On Wed, 11 Feb 2009 17:07:16 +0200
> Boaz Harrosh <bharrosh@panasas.com> wrote:
> 
>>>
>>>
>> Sure it can pass pages to ULD but then how ULD maks a request out of
>> pages?
> 
> If you extend blk_rq_map_kern as James did, your ULD make a request
> out of passed pages, that is, the block layer properly builds a
> request with bio(s).

What? I don't understand?
blk_rq_map_kern takes a kernel-pointer and length, how to pass array
of page* ?

> 
> I think that another possible option is adding a new mapping function
> that can handle multiple bios for kernel buffers (as Mike extended
> blk_rq_map_user).
> 

Yes adding a new mapping function can help. Please note I need to
add (append) pages same as bio_add_pc_page() but on request level.

And yet we had an entry that did exactly that, blk_rq_append_bio(), no?

> 
>> And it gets more complicated then that (above multiple times)
> 
> I don't think so. If you don't have time to work on it, please let me
> know. I'll fix OSD ULD.

I have all the time in the world, And yes what James did with blk_rq_map_kern
will help with appending other osd segments on top of data.

If you propose the appropriate new API for block request level I can implement
that in block, and also in OSD. What other entry you want to add/change that solve
my need?

Thanks
Boaz


  reply	other threads:[~2009-02-11 15:41 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
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 [this message]
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=4992F1AF.9060702@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.