All of lore.kernel.org
 help / color / mirror / Atom feed
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
To: bharrosh@panasas.com
Cc: fujita.tomonori@lab.ntt.co.jp,
	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: Thu, 12 Feb 2009 01:04:34 +0900	[thread overview]
Message-ID: <20090212010454J.fujita.tomonori@lab.ntt.co.jp> (raw)
In-Reply-To: <4992F1AF.9060702@panasas.com>

On Wed, 11 Feb 2009 17:41:35 +0200
Boaz Harrosh <bharrosh@panasas.com> wrote:

> 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* ?

You can call it multiple times. But I guess that you need something
new since you need to handle user pages.


> > 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.

I think that what you need already exists.

See how st uses blk_rq_map_user() in scsi-misc (keywords: rq_map_data
and null_mapped). Please read it before saying something like 'we need
to handle kernel buffer'.


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

Using blk_rq_append_bio in SCSI is unacceptable.


> >> 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?

If you have time, how about making a proposal. ;)

But as I wrote above, I think that blk_rq_map_user() works for you.

  reply	other threads:[~2009-02-11 16:04 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
2009-02-11 16:04                         ` FUJITA Tomonori [this message]
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=20090212010454J.fujita.tomonori@lab.ntt.co.jp \
    --to=fujita.tomonori@lab.ntt.co.jp \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=bharrosh@panasas.com \
    --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.