Re: regression with c/s 21223

[Jim Fehlig <jfehlig@novell.com>]

Keir Fraser wrote:
> On 07/05/2010 14:37, "Jim Fehlig" <jfehlig@novell.com> 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