Hello,

Why do cciss/cpqarray directly call "bio_endio" and "disk_stat_add"
when request completion instead of using "end_that_request_first"?
Are there any problems in using "end_that_request_first"?


BACKGROUND:
I'm working on refining request completion procedures like:
    Before: 2 steps completion using "end_that_request_{first/chunk}"
            and "end_that_request_last"
    After:  1 step completion using generic block-layer helper
            which I'm calling "blk_end_request"
"blk_end_request" works like calling "__end_that_request_first"
and "end_that_request_last".
<http://marc.info/?l=linux-kernel&m=116846938806220&w=2>

However, while auditing various drivers, I found some drivers
are not using "end_that_request_{first/chunk}".
So I have to be careful not to break such drivers.

In the case of cciss/cpqarray, they call block layer functions
directly instead of using "end_that_request_first".
    o. Call blk_trace_add_rq() (cpqarray doesn't call it though)
    o. Call disk_stat_add()
    o. Complete bios in a request using bio_endio()
But "__end_that_request_first" does all of them.
So I can't understand why cciss/cpqarray don't use it.
Hence the question above.

Are there any problems in using "end_that_request_first" like
the patch below?
If no problem, testing the patch would be very helpful because I have
no hardware for those device drivers.  (I have done only build test.)

If it causes problems, some tricky work may be needed to skip
"__end_that_request_first" in "blk_end_request".

Thanks,
Kiyoshi Ueda


Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>

diff -rupN 2.6.23-rc1-mm1/drivers/block/cciss.c refine/drivers/block/cciss.c
--- 2.6.23-rc1-mm1/drivers/block/cciss.c	2007-07-25 14:00:10.000000000 -0400
+++ refine/drivers/block/cciss.c	2007-07-26 11:29:32.000000000 -0400
@@ -1250,6 +1250,7 @@ static void cciss_softirq_done(struct re
 	unsigned long flags;
 	u64bit temp64;
 ...
[ message continues ]