bidi support: bidirectional request

- Instantiate another request_io_part in request for bidi_read.
- Define & Implement new API for accessing bidi parts.
- API to Build bidi requests and map to sglists.
- Define new end_that_request_block() function to end a complete request.

---
 block/elevator.c       |    7 +---
 block/ll_rw_blk.c      |  113 ++++++++++++++++++++++++++++++++++++++++++------
 include/linux/blkdev.h |   49 ++++++++++++++++++++-
 3 files changed, 149 insertions(+), 20 deletions(-)

index 0e9ea69..53b552e 100644
@@ -741,14 +741,9 @@ struct request *elv_next_request(request
 			rq = NULL;
 			break;
 		} else if (ret == BLKPREP_KILL) {
-			int nr_bytes = rq_uni(rq)->hard_nr_sectors << 9;
-
-			if (!nr_bytes)
-				nr_bytes = rq_uni(rq)->data_len;
-
 			blkdev_dequeue_request(rq);
 			rq->cmd_flags |= REQ_QUIET;
-			end_that_request_chunk(rq, 0, nr_bytes);
+			end_that_request_block(rq, 0);
 			end_that_request_last(rq, 0);
 		} else {
 			printk(KERN_ERR "%s: bad return=%d\n", __FUNCTION__,

Actually, this approach looks to be a bit too narrow. You seem to be predicating on the idea that the bidirectional will transfer in and out of the same area. For some of the frame in/frame out stuff, we probably need the read and write areas for the bidirectional request to be separated.

James

Hmm, our proposal introduces two separate and independent i/o areas. One used for uni-directional transfers and for bidi data output, the other is used for bidi data input so we're in agreement.

Benny