Xen devel - Apr 2009 - Re: [5 Patches] Synchronize blktap with citrix blktap2.

I started to look into these patches, to try to evaluate how much
performance improvement this re-write gives, but have a problem with the
way this works.

As I understand the patch set in userspace you:
1. move the old blktap dir to blktap_old
2. introduce the new blktap2 code in blktap

However, these changes that you are making to qemu merely link against
the old libraries, rather than adjusting the include paths to include
the new headers, and compile/link against the new blktap2?

Won''t this cause problems when you actually go to use tapdisk?

Am I missing something here?

Ben


        I''ve been reminded that the ioemu patch to update the blktap
dependencies in that repo is still necessary. It is available here:
       
http://www.cs.ubc.ca/~dmeyer/blktap2/tools_ioemu_dir_use_blktap_old.patch
        
        --Dutch
                        


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

You''ve got the right idea, but it''s no problem.  If
you''re using blktap2
(eg tap:tapdisk:aio:...) the usermode scripts will create a new udev 
device for the guest to mount.  This is entirely orthogonal to qemu, so 
there''s no problem.

If the qemu folks wanted to use blktap2 they could have the guest mount a 
blktap2 disk like it was any other raw device.  However, they''ve
decided
to instead replicate the original blktap functionality in their own code 
base.  So if you''re using qemu''s blktap you''re not
using blktap2.  Again,
not a problem.

--Dutch

On Fri, 3 Apr 2009, Ben Guthro wrote:
> I started to look into these patches, to try to evaluate how much
> performance improvement this re-write gives, but have a problem with the
> way this works.
>
> As I understand the patch set in userspace you:
> 1. move the old blktap dir to blktap_old
> 2. introduce the new blktap2 code in blktap
>
> However, these changes that you are making to qemu merely link against
> the old libraries, rather than adjusting the include paths to include
> the new headers, and compile/link against the new blktap2?
>
> Won''t this cause problems when you actually go to use tapdisk?
>
> Am I missing something here?
>
> Ben
>
>
>        I''ve been reminded that the ioemu patch to update the
blktap dependencies in that repo is still necessary. It is available here:
>       
http://www.cs.ubc.ca/~dmeyer/blktap2/tools_ioemu_dir_use_blktap_old.patch
>
>        --Dutch
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

This patch compiles against the new blktap...but not really knowing much
about the code, I can''t tell you if I have broken something or not. It
remains untested, for now because of this.

It seems that the "readonly" flag was removed...but I can''t
seem to find
much documentation, or examples on how this might be used, so I might be
way off base here

The introduction of the new blktaplib.h does introduce a significant
number of new warnings to the qemu build though.



On Fri, 2009-04-03 at 10:53 -0400, Ben Guthro wrote:
> I started to look into these patches, to try to evaluate how much
> performance improvement this re-write gives, but have a problem with the
> way this works.
> 
> As I understand the patch set in userspace you:
> 1. move the old blktap dir to blktap_old
> 2. introduce the new blktap2 code in blktap
> 
> However, these changes that you are making to qemu merely link against
> the old libraries, rather than adjusting the include paths to include
> the new headers, and compile/link against the new blktap2?
> 
> Won''t this cause problems when you actually go to use tapdisk?
> 
> Am I missing something here?
> 
> Ben
> 
> 
>         I''ve been reminded that the ioemu patch to update the
blktap dependencies in that repo is still necessary. It is available here:
>        
http://www.cs.ubc.ca/~dmeyer/blktap2/tools_ioemu_dir_use_blktap_old.patch
>         
>         --Dutch
>                         

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> It seems that the "readonly" flag was removed...but I
can''t seem to find
> much documentation, or examples on how this might be used, so I might be
> way off base here
Internally, the flag changed to TD_OPEN_RDONLY, but that shouldn''t have
any effect from a user perspective.  Normal usage shouldn''t be changed 
from the original blktap, you should be able to boot tap disks just as 
before.

Internally, the other tap drivers have all been updated to take advantage 
of the new (and simplified) API.  If you take a look there you''ll see
the
updates.
> The introduction of the new blktaplib.h does introduce a significant
> number of new warnings to the qemu build though.
This is unexpected, but I see now how it could happen under certain 
conditions.  I will fix this today by NOT installing the "new"
blktaplib.h
into /usr/include.  This will ensure that anyone who has build anything 
with #include <blktaplib.h> dependencies will continue to see the old 
version, which should be appropriate until the old blktap is fully 
removed.

--Dutch

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

The build system update I promised is here:
http://www.cs.ubc.ca/~dmeyer/blktap2/userspace_patches.tgz

This removes the blktap2''s blktaplib.h from /usr/include so that code
with
blktap dependencies doesn''t get confused.

Other patches listed below remain unchanged:
http://www.cs.ubc.ca/~dmeyer/blktap2/kernel_patches.tgz
http://www.cs.ubc.ca/~dmeyer/blktap2/tools_ioemu_dir_use_blktap_old.patch

--Dutch

On Fri, 3 Apr 2009, Dutch Meyer wrote:
>> It seems that the "readonly" flag was removed...but I
can''t seem to find
>> much documentation, or examples on how this might be used, so I might
be
>> way off base here
>
> Internally, the flag changed to TD_OPEN_RDONLY, but that shouldn''t
have any
> effect from a user perspective.  Normal usage shouldn''t be changed
from the
> original blktap, you should be able to boot tap disks just as before.
>
> Internally, the other tap drivers have all been updated to take advantage
of
> the new (and simplified) API.  If you take a look there you''ll see
the
> updates.
>
>> The introduction of the new blktaplib.h does introduce a significant
>> number of new warnings to the qemu build though.
>
> This is unexpected, but I see now how it could happen under certain 
> conditions.  I will fix this today by NOT installing the "new"
blktaplib.h
> into /usr/include.  This will ensure that anyone who has build anything
with
> #include <blktaplib.h> dependencies will continue to see the old
version,
> which should be appropriate until the old blktap is fully removed.
>
> --Dutch
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel