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] [PATCH 0 of 7] libxl: refactor tap disk handling

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [PATCH 0 of 7] libxl: refactor tap disk handling
From: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date: Thu, 07 Apr 2011 10:52:26 +0100
Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
Delivery-date: Thu, 07 Apr 2011 02:53:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mercurial-patchbomb/1.6.4
I'm not personally convinced that support for blktap2 devices should
be conflated in libxl with the PV block backend support but given it's
there lets at least correct it.

In a blktap2 system there is no "tap" PV backend type. blktap2 exposes
a standard block device and this is passed to a guest using the
standard blkback "vbd" (sometimes called "phy") backend. Drop the
"tap" backend type and associated (libxl internal ) DEVICE_TAP
enumeration value.

Also try and clarify the paths which fallback from blktap2 to qdisk
when the former is not present. Falling through a switch statement is
a neat way of doing this in some cases, but I don't think this is one
of them.

Xen-devel mailing list