Messages in this thread | | | Date | Tue, 04 Mar 2008 09:10:06 +0100 | From | Hannes Reinecke <> | Subject | Re: [RFC PATCH 1/3] block: add rq->complete_io hook for request stacking |
| |
Hi Kiyoshi,
Kiyoshi Ueda wrote: > Hi Hannes, > > On Mon, 03 Mar 2008 17:24:50 +0100, Hannes Reinecke wrote: >> Hi Kiyoshi, >> >> Kiyoshi Ueda wrote: >>> This patch adds ->complete_io() hook for request stacking. >>> Request stacking drivers (such as request-based dm) can set >>> a callback for completion. >>> (The hook is not called in blk_end_io(), since request-based dm uses >>> it for clone completion in the following appendix patches.) >>> >> [ .. ] >> I would rather have rq->complete_io() to be pointing to blk_end_io in the >> default case, this way rq->complete_io() would always be valid and we >> would be saving us the if() clause. > > Thank you for the comment. > > I'm thinking about an idea come from Mike and Jens after the session > at LSF'08: > o stacking driver clones both bio and request and uses > bio->bi_end_io and rq->end_io > o stacking driver uses blk_complete_request() in rq->end_io > so that stacking driver can work without queue lock > With this idea, we don't need to add the new hook to request, > and we can use request stacking on drivers using __blk_end_request(). > Huh? I can't really imagine how this should work. If you start using bio->bi_end_io() for stacking usage you'll end up with doing weird thing with the bios ... Can you elaborate a bit more here?
> Currently, I'm trying to convert request-based dm to use the idea above. > I'll post the new version as a RFC in the near future. > Oh, cool. Looking forward to it.
Cheers,
Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |