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


Re: [Xen-devel] regression with c/s 21223

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] regression with c/s 21223
From: Jim Fehlig <jfehlig@xxxxxxxxxx>
Date: Fri, 07 May 2010 13:31:01 -0600
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ryan O'Connor <rjo@xxxxxxxxx>
Delivery-date: Fri, 07 May 2010 12:31:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C80A168A.13AE5%keir.fraser@xxxxxxxxxxxxx>
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>
References: <C80A168A.13AE5%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20081112)
Keir Fraser wrote:
> On 07/05/2010 14:37, "Jim Fehlig" <jfehlig@xxxxxxxxxx> 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 :-).


Xen-devel mailing list