Re: [Xen-devel] [PATCH RFC v2 0/3] tools: Allow building XenServer's blktap 2.5 as an external tree.

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 04/16/2015 04:56 PM, George Dunlap wrote:
> For some time, the blktap2 in-tree has bitrotted.  Many years ago the
> XenServer team at Citrix forked the code into a separate repository;
> several attempts have been made to upstream those changes back into
> Xen, to no avail.
> 
> The blktap code at the moment is the only source of performant vhd
> format integration.  It's additionally in use by projects like the
> COLO project.
> 
> This patch series removes the in-tree blktap2 code and enables xen to
> detect and build against the XenServer blktap tree.  I've gotten
> agreement from the XenServer team to act as an upstream -- to accept
> patches fixing bugs, to help track down errors, and to attempt to help
> fix build breakages introduced by development.
> 
> At the moment this patch is against the "blktap2" branch of
> XenServer's blktap.git.  (This has been sometimes known as "blktap
> 2.5".)  This branch is maintianed in order to provide a buildroot for
> OpenStack, and has also been used by the CentOS xen packages for
> several years now.
> 
> The series consists of three patches:
> 
> 1/3 Remove the blktap2 tree and temporarily disable it in config
> 
> 2/3 Port libxl to use the upstream blktap2.
> 
> 3/3 Detect blktap2 and enable it by default if detected.
> 
> The first patch is pretty massive and mostly not very interesting;
> I'll be sending a modified patch with the interesting bits.  The full
> patch series can be found here:
> 
> git://xenbits.xen.org/people/gdunlap/xen.git  out/blktap25/rfc-v2
> 
> This series has some niggles (noted in the patches themselves), and so
> it not yet ready to apply as-is.
> 
> One of the big ones is that the blktap headers are borked: you can't
> actually include them from where they get installed.  This is
> something I'm going to try to address upstream.

I forgot to add,

Difference vs v1: build as an external library, rather than cloning and
building it internally.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel