From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: [PATCH 0 of 7] libxl: refactor tap disk handling Date: Thu, 7 Apr 2011 14:31:45 +0200 Message-ID: <4D9DAEB1.2070407@amd.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 04/07/11 11:52, Ian Campbell wrote: > 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. What happens on a no-blktap2 system? > > 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 > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632