From: Mike Christie <michaelc@cs.wisc.edu>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: device-mapper development <dm-devel@redhat.com>,
mchristi@redhat.com, linux-kernel@vger.kernel.org,
agk@redhat.com
Subject: Re: Re: [RFC PATCH 1/8] rqbased-dm: allow blk_get_request() to be called from interrupt context
Date: Thu, 21 Dec 2006 12:30:56 -0600 [thread overview]
Message-ID: <458AD2E0.40807@cs.wisc.edu> (raw)
In-Reply-To: <20061221182432.GB17199@kernel.dk>
Jens Axboe wrote:
> On Thu, Dec 21 2006, Mike Christie wrote:
>> Or the block layer code could set up the clone too. elv_next_request
>> could prep a clone based on the orignal request for the driver then dm
>> would not have to worry about that part.
>
> It really can't, since it doesn't know how to allocate the clone
> request. I'd rather export this functionality as helpers.
>
What do you think about dm's plan to break up make_request into a
mapping function and in to the part the builds the bio into a request.
This would fit well with them being helpers and being able to allocate
the request from the correct context.
I see patches for that did not get posted, but I thought Joe and
Alasdair used to talk about that a lot and in the dm code I think there
is sill comments about doing it. Maybe the dm comments mentioned the
merge_fn, but I guess the merge_fn did not fit what they wanted to do or
something. I think Alasdair talked about this at one of his talks at OLS
or it was in a proposal for the kernel summit. I can dig up the mail if
you want.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Christie <michaelc@cs.wisc.edu>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: device-mapper development <dm-devel@redhat.com>,
mchristi@redhat.com, linux-kernel@vger.kernel.org,
agk@redhat.com
Subject: Re: [dm-devel] Re: [RFC PATCH 1/8] rqbased-dm: allow blk_get_request() to be called from interrupt context
Date: Thu, 21 Dec 2006 12:30:56 -0600 [thread overview]
Message-ID: <458AD2E0.40807@cs.wisc.edu> (raw)
In-Reply-To: <20061221182432.GB17199@kernel.dk>
Jens Axboe wrote:
> On Thu, Dec 21 2006, Mike Christie wrote:
>> Or the block layer code could set up the clone too. elv_next_request
>> could prep a clone based on the orignal request for the driver then dm
>> would not have to worry about that part.
>
> It really can't, since it doesn't know how to allocate the clone
> request. I'd rather export this functionality as helpers.
>
What do you think about dm's plan to break up make_request into a
mapping function and in to the part the builds the bio into a request.
This would fit well with them being helpers and being able to allocate
the request from the correct context.
I see patches for that did not get posted, but I thought Joe and
Alasdair used to talk about that a lot and in the dm code I think there
is sill comments about doing it. Maybe the dm comments mentioned the
merge_fn, but I guess the merge_fn did not fit what they wanted to do or
something. I think Alasdair talked about this at one of his talks at OLS
or it was in a proposal for the kernel summit. I can dig up the mail if
you want.
next prev parent reply other threads:[~2006-12-21 18:30 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-19 22:11 [RFC PATCH 1/8] rqbased-dm: allow blk_get_request() to be called from interrupt context Kiyoshi Ueda
2006-12-19 22:11 ` Kiyoshi Ueda
2006-12-20 13:48 ` Jens Axboe
2006-12-20 13:48 ` Jens Axboe
2006-12-20 17:50 ` Kiyoshi Ueda
2006-12-20 17:50 ` Kiyoshi Ueda
2006-12-20 18:49 ` Jens Axboe
2006-12-20 18:49 ` Jens Axboe
2006-12-20 21:55 ` Kiyoshi Ueda
2006-12-20 21:55 ` Kiyoshi Ueda
2006-12-21 7:53 ` Jens Axboe
2006-12-21 7:53 ` Jens Axboe
2006-12-21 17:59 ` Mike Christie
2006-12-21 17:59 ` [dm-devel] " Mike Christie
2006-12-21 18:13 ` Mike Christie
2006-12-21 18:13 ` [dm-devel] " Mike Christie
2006-12-21 18:24 ` Jens Axboe
2006-12-21 18:24 ` [dm-devel] " Jens Axboe
2006-12-21 18:30 ` Mike Christie [this message]
2006-12-21 18:30 ` Mike Christie
2006-12-21 18:36 ` Mike Christie
2006-12-21 18:36 ` [dm-devel] " Mike Christie
2006-12-21 18:42 ` Jens Axboe
2006-12-21 18:42 ` [dm-devel] " Jens Axboe
2006-12-21 18:57 ` Mike Christie
2006-12-21 18:57 ` [dm-devel] " Mike Christie
2006-12-21 19:19 ` Jens Axboe
2006-12-21 19:19 ` [dm-devel] " Jens Axboe
2006-12-21 22:22 ` Mike Christie
2006-12-21 22:22 ` [dm-devel] " Mike Christie
2006-12-21 18:40 ` Jens Axboe
2006-12-21 18:40 ` [dm-devel] " Jens Axboe
2006-12-21 18:11 ` Kiyoshi Ueda
2006-12-21 18:11 ` Kiyoshi Ueda
2006-12-21 18:21 ` Jens Axboe
2006-12-21 18:21 ` Jens Axboe
2006-12-20 19:11 ` Chen, Kenneth W
2006-12-20 19:11 ` Chen, Kenneth W
2006-12-20 19:17 ` Jens Axboe
2006-12-20 19:17 ` Jens Axboe
2006-12-22 14:01 ` Christoph Hellwig
2006-12-22 14:01 ` Christoph Hellwig
2006-12-22 17:32 ` Jens Axboe
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=458AD2E0.40807@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mchristi@redhat.com \
/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.