From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: regression with c/s 21223 Date: Fri, 07 May 2010 13:31:01 -0600 Message-ID: <4BE46A75.8010207@novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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: Keir Fraser Cc: Xen-devel , Ryan O'Connor List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 07/05/2010 14:37, "Jim Fehlig" wrote: > > >>> Way outside my comfort zone with xend I'm afraid. Do you think we need >>> explicit differentiation between tap and tap2? >>> >>> >> That is certainly an approach we are considering for our Xen 4.0-based >> packages - see attached patch. As mentioned previously, we are not yet >> supporting blktap2 so such a change seems appropriate in our case. >> > > Does that simple patch really "just work"? It does for me, and I've done quite a bit of testing using 'tap:foo' and 'tap2:foo', with and without blktap2 module loaded. > I suppose it really just punts > the tap2 issues, unless we also get rid of the tap2-falls-back-to-tap1 > logic? > It reverts 2 hunks of c/s 19874, which implicitly converts the device to tap2 in a xend client app! If the same configuration is provided to xend through libvirt, this implicit conversion does not occur. I'd suspect this is true for direct users of XenAPI as well. But yes, I agree that if an explicit differentiation between tap and tap2 exists, then the tap2-fall-back-to-tap1 logic should be removed. It would be nice to get input from others, particularly authors of blktap2 integration patches :-). Regards, Jim