Files
kernel_arpi/include/linux
Tejun Heo 2e60e02297 block: clean up request completion API
Request completion has gone through several changes and became a bit
messy over the time.  Clean it up.

1. end_that_request_data() is a thin wrapper around
   end_that_request_data_first() which checks whether bio is NULL
   before doing anything and handles bidi completion.
   blk_update_request() is a thin wrapper around
   end_that_request_data() which clears nr_sectors on the last
   iteration but doesn't use the bidi completion.

   Clean it up by moving the initial bio NULL check and nr_sectors
   clearing on the last iteration into end_that_request_data() and
   renaming it to blk_update_request(), which makes blk_end_io() the
   only user of end_that_request_data().  Collapse
   end_that_request_data() into blk_end_io().

2. There are four visible completion variants - blk_end_request(),
   __blk_end_request(), blk_end_bidi_request() and end_request().
   blk_end_request() and blk_end_bidi_request() uses blk_end_request()
   as the backend but __blk_end_request() and end_request() use
   separate implementation in __blk_end_request() due to different
   locking rules.

   blk_end_bidi_request() is identical to blk_end_io().  Collapse
   blk_end_io() into blk_end_bidi_request(), separate out request
   update into internal helper blk_update_bidi_request() and add
   __blk_end_bidi_request().  Redefine [__]blk_end_request() as thin
   inline wrappers around [__]blk_end_bidi_request().

3. As the whole request issue/completion usages are about to be
   modified and audited, it's a good chance to convert completion
   functions return bool which better indicates the intended meaning
   of return values.

4. The function name end_that_request_last() is from the days when it
   was a public interface and slighly confusing.  Give it a proper
   internal name - blk_finish_request().

5. Add description explaning that blk_end_bidi_request() can be safely
   used for uni requests as suggested by Boaz Harrosh.

The only visible behavior change is from #1.  nr_sectors counts are
cleared after the final iteration no matter which function is used to
complete the request.  I couldn't find any place where the code
assumes those nr_sectors counters contain the values for the last
segment and this change is good as it makes the API much more
consistent as the end result is now same whether a request is
completed using [__]blk_end_request() alone or in combination with
blk_update_request().

API further cleaned up per Christoph's suggestion.

[ Impact: cleanup, rq->*nr_sectors always updated after req completion ]

Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Boaz Harrosh <bharrosh@panasas.com>
Cc: Christoph Hellwig <hch@infradead.org>
2009-04-28 07:37:35 +02:00
..
2009-04-07 10:23:34 +01:00
2009-04-06 20:00:51 -04:00
2009-04-01 08:59:23 -07:00
2009-04-01 08:59:23 -07:00
2009-04-28 07:37:28 +02:00
2009-04-23 10:06:35 +01:00
2009-04-03 14:53:32 -07:00
2009-04-03 14:53:32 -07:00
2009-04-03 09:48:29 -07:00
2009-04-02 19:04:53 -07:00
2009-04-13 15:04:29 -07:00
2009-04-26 09:20:38 -07:00
2009-04-21 13:41:48 -07:00
2009-04-21 13:41:48 -07:00
2009-04-02 19:04:49 -07:00
2009-04-06 16:06:26 +01:00
2009-04-28 07:37:28 +02:00
2009-04-07 08:12:38 +02:00
2009-04-02 19:04:48 -07:00
2009-04-03 17:41:23 -07:00
2009-04-01 13:28:15 -04:00
2009-04-03 17:41:12 -07:00
2009-04-01 08:59:13 -07:00
2009-04-01 08:59:13 -07:00
2009-04-13 15:04:32 -07:00
2009-04-13 14:51:23 -07:00
2009-04-24 08:54:21 +02:00
2009-04-01 08:59:13 -07:00
2009-04-01 08:59:24 -07:00
2009-04-08 14:33:38 -07:00
2009-04-13 15:04:29 -07:00
2009-04-03 12:23:06 +02:00
2009-04-21 19:40:00 -07:00
2009-04-03 12:23:06 +02:00
2009-04-01 08:59:15 -07:00
2009-04-02 19:05:01 -07:00
2009-04-17 10:50:27 -07:00