From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: [PATCH 0 of 7] libxl: refactor tap disk handling
Date: Thu, 07 Apr 2011 10:52:26 +0100
Message-ID: <patchbomb.1302169946@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: xen-devel@lists.xensource.com
Cc: Ian Campbell <ian.campbell@citrix.com>
List-Id: xen-devel@lists.xenproject.org

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.