From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo Date: Mon, 30 Mar 2015 15:43:07 +0100 Message-ID: <551960FB.8090806@eu.citrix.com> References: <1427373970-25399-1-git-send-email-george.dunlap@eu.citrix.com> <1427373970-25399-3-git-send-email-george.dunlap@eu.citrix.com> <20150330143322.GH25911@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150330143322.GH25911@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Dave Scott , Wen Congyang , Jonathan Ludlam , xen-devel@lists.xen.org, Ian Jackson , Yang Hongyang , Ian Campbell List-Id: xen-devel@lists.xenproject.org On 03/30/2015 03:33 PM, Wei Liu wrote: > On Thu, Mar 26, 2015 at 12:46:08PM +0000, George Dunlap wrote: >> Download and build XenServer's blktap as an external tree, similar to >> qemu-xen. >> >> As of this patch we just download and build it, but don't install or >> use it. >> >> Signed-off-by: George Dunlap >> --- >> >> FIXME: Directly use the XenServer github repo for now, while we're >> discussing things. If we decide to take this series, we'll have to >> clone the tree on xenbits and remove the FIXME line. >> > > IMHO we need to support --with-system-blktap= in configure in case > distro wants to package blktap separately. Not sure if in practice this > makes sense since AIUI blktap is only used by Xen. I agree that would be ideal; however, it's not so simple, because at the moment libxl links directly against libblktap. This would mean: 1) Changing libxl so that it could dynamically detect the presence of the proper version of libblktap at runtime and use the stubbed-out defaults if not available. 2) Changing libxl to exec() tapctl rather than making library calls. (This might involve making sure that tapctl actually has all the functionality we need.) #1 is even more difficult because at the moment blktap isn't really designed to have stable external versions -- it would involve adding a library version and all the fun stuff we already do with libxl. #2 has another potential advantage: using the command-line may make it easier to be forward-compatible, since adding options won't break (unlike adding arguments to a function signature). (Although, I think for API compatibility, changing the public functions to use structs is probably a more reliable thing to do.) Either way, I think that's something we should start to look at after pivoting to the external blktap repo. -George