[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1238593472-30360-2-git-send-email-tj@kernel.org>
Date: Wed, 1 Apr 2009 22:44:16 +0900
From: Tejun Heo <tj@...nel.org>
To: axboe@...nel.dk, bharrosh@...asas.com,
linux-kernel@...r.kernel.org, fujita.tomonori@....ntt.co.jp
Cc: Tejun Heo <tj@...nel.org>
Subject: [PATCH 01/17] blk-map: move blk_rq_map_user() below blk_rq_map_user_iov()
Impact: code reorganization
blk_rq_map_user() is about to be reimplemented using
blk_rq_map_user_iov(). Move it below blk_rq_map_user_iov() so that
the actual conversion patch is easier to read.
Signed-off-by: Tejun Heo <tj@...nel.org>
---
block/blk-map.c | 70 +++++++++++++++++++++++++++---------------------------
1 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/block/blk-map.c b/block/blk-map.c
index a43c93c..fdef591 100644
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@ -41,41 +41,6 @@ static int __blk_rq_unmap_user(struct bio *bio)
}
/**
- * blk_rq_map_user - map user data to a request, for REQ_TYPE_BLOCK_PC usage
- * @q: request queue where request should be inserted
- * @rq: request structure to fill
- * @map_data: pointer to the rq_map_data holding pages (if necessary)
- * @ubuf: the user buffer
- * @len: length of user data
- * @gfp_mask: memory allocation flags
- *
- * Description:
- * Data will be mapped directly for zero copy I/O, if possible. Otherwise
- * a kernel bounce buffer is used.
- *
- * A matching blk_rq_unmap_user() must be issued at the end of I/O, while
- * still in process context.
- *
- * Note: The mapped bio may need to be bounced through blk_queue_bounce()
- * before being submitted to the device, as pages mapped may be out of
- * reach. It's the callers responsibility to make sure this happens. The
- * original bio must be passed back in to blk_rq_unmap_user() for proper
- * unmapping.
- */
-int blk_rq_map_user(struct request_queue *q, struct request *rq,
- struct rq_map_data *map_data, void __user *ubuf,
- unsigned long len, gfp_t gfp_mask)
-{
- struct sg_iovec iov;
-
- iov.iov_base = ubuf;
- iov.iov_len = len;
-
- return blk_rq_map_user_iov(q, rq, map_data, &iov, 1, len, gfp_mask);
-}
-EXPORT_SYMBOL(blk_rq_map_user);
-
-/**
* blk_rq_map_user_iov - map user data to a request, for REQ_TYPE_BLOCK_PC usage
* @q: request queue where request should be inserted
* @rq: request to map data to
@@ -151,6 +116,41 @@ int blk_rq_map_user_iov(struct request_queue *q, struct request *rq,
EXPORT_SYMBOL(blk_rq_map_user_iov);
/**
+ * blk_rq_map_user - map user data to a request, for REQ_TYPE_BLOCK_PC usage
+ * @q: request queue where request should be inserted
+ * @rq: request structure to fill
+ * @map_data: pointer to the rq_map_data holding pages (if necessary)
+ * @ubuf: the user buffer
+ * @len: length of user data
+ * @gfp_mask: memory allocation flags
+ *
+ * Description:
+ * Data will be mapped directly for zero copy I/O, if possible. Otherwise
+ * a kernel bounce buffer is used.
+ *
+ * A matching blk_rq_unmap_user() must be issued at the end of I/O, while
+ * still in process context.
+ *
+ * Note: The mapped bio may need to be bounced through blk_queue_bounce()
+ * before being submitted to the device, as pages mapped may be out of
+ * reach. It's the callers responsibility to make sure this happens. The
+ * original bio must be passed back in to blk_rq_unmap_user() for proper
+ * unmapping.
+ */
+int blk_rq_map_user(struct request_queue *q, struct request *rq,
+ struct rq_map_data *map_data, void __user *ubuf,
+ unsigned long len, gfp_t gfp_mask)
+{
+ struct sg_iovec iov;
+
+ iov.iov_base = ubuf;
+ iov.iov_len = len;
+
+ return blk_rq_map_user_iov(q, rq, map_data, &iov, 1, len, gfp_mask);
+}
+EXPORT_SYMBOL(blk_rq_map_user);
+
+/**
* blk_rq_unmap_user - unmap a request with user data
* @bio: start of bio list
*
--
1.6.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists