This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [RFC PATCH 33/33] Add Xen virtual block device driver.

To: Dave Boutcher <boutcher@xxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC PATCH 33/33] Add Xen virtual block device driver.
From: Jeff Garzik <jeff@xxxxxxxxxx>
Date: Tue, 18 Jul 2006 12:25:36 -0400
Cc: Andrew Morton <akpm@xxxxxxxx>, Zachary Amsden <zach@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Pratt <ian.pratt@xxxxxxxxxxxxx>, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Andi Kleen <ak@xxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Tue, 18 Jul 2006 09:26:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <17596.56260.541661.919437@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060718091807.467468000@xxxxxxxxxxxx> <20060718091958.657332000@xxxxxxxxxxxx> <17596.56260.541661.919437@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060614)
Dave Boutcher wrote:
On Tue, 18 Jul 2006 00:00:33 -0700, Chris Wright <chrisw@xxxxxxxxxxxx> said:
The block device frontend driver allows the kernel to access block
devices exported exported by a virtual machine containing a physical
block device driver.

First, I think this belongs in drivers/block (and the network driver
belongs in drivers/net).  If we're going to bring xen to the party,
lets not leave it hiding out in a corner.

Strongly agreed.

+static void connect(struct blkfront_info *);
+static void blkfront_closing(struct xenbus_device *);
+static int blkfront_remove(struct xenbus_device *);
+static int talk_to_backend(struct xenbus_device *, struct blkfront_info *);
+static int setup_blkring(struct xenbus_device *, struct blkfront_info *);
+static void kick_pending_request_queues(struct blkfront_info *);
+static irqreturn_t blkif_int(int irq, void *dev_id, struct pt_regs *ptregs);
+static void blkif_restart_queue(void *arg);
+static void blkif_recover(struct blkfront_info *);
+static void blkif_completion(struct blk_shadow *);
+static void blkif_free(struct blkfront_info *, int);

I'm pretty sure you can rearrange the code to get rid of the forward

I've never thought this was useful... If the function ordering helps the human...

+       switch (backend_state) {
+       case XenbusStateUnknown:
+       case XenbusStateInitialising:
+       case XenbusStateInitWait:
+       case XenbusStateInitialised:
+       case XenbusStateClosed:

This actually should get fixed elsewhere, but SillyCaps???


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>