This patch converts virtio_blk to use __blk_end_request() directly
so that end_{queued|dequeued}_request() can be removed.
Related 'uptodate' argument is converted to 'error'.

__blk_end_request() takes care of dequeueing request like below:

        if (!list_empty(&rq->queuelist))
                blkdev_dequeue_request(rq);

In the case of virtio_blk, blkdev_dequeue_request() has been done
in do_virtblk_request() and the queuelist is empty in blk_done().
So __blk_end_request() doesn't call blkdev_dequeue_request() and
the behavior of blk_done() doesn't change.

Cc: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Kiyoshi Ueda <[EMAIL PROTECTED]>
Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
---
 drivers/block/virtio_blk.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

Index: 2.6.24-rc7/drivers/block/virtio_blk.c
===================================================================
--- 2.6.24-rc7.orig/drivers/block/virtio_blk.c
+++ 2.6.24-rc7/drivers/block/virtio_blk.c
@@ -45,20 +45,20 @@ static bool blk_done(struct virtqueue *v
 
        spin_lock_irqsave(&vblk->lock, flags);
        while ((vbr = vblk->vq->vq_ops->get_buf(vblk->vq, &len)) != NULL) {
-               int uptodate;
+               int error;
                switch (vbr->in_hdr.status) {
                case VIRTIO_BLK_S_OK:
-                       uptodate = 1;
+                       error = 0;
                        break;
                case VIRTIO_BLK_S_UNSUPP:
-                       uptodate = -ENOTTY;
+                       error = -ENOTTY;
                        break;
                default:
-                       uptodate = 0;
+                       error = -EIO;
                        break;
                }
 
-               end_dequeued_request(vbr->req, uptodate);
+               __blk_end_request(vbr->req, error, blk_rq_bytes(vbr->req));
                list_del(&vbr->list);
                mempool_free(vbr, vblk->pool);
        }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to