Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Mar 30, 2015 at 03:43:07PM +0100, George Dunlap wrote:
> 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 <george.dunlap@xxxxxxxxxxxxx>
> >> ---
> >>
> >> 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.
> 

This should be done in ./configure too, not during libxl build /
runtime.  If libblktap is not present during ./configure  then libxl
just use stubs.

> 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.)
> 

There is no need to change to exec() at runtime. See above.

> #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.
> 

It blktap is to be maintained as external project to get wider usage
outside of Xen then this is a thing they have to do, isn't it?
Otherwise this is just an effort to separate blktap to an external tree,
Xen is still coupled with a certain blktap changeset. Not saying this
itself is a problem but it would be better to clarify what's the future
expectation of blktap as a project.

> #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.
> 

Agreed. I don't mean to have --with-system-blktap= as prerequisite of
this series being accepted.

Wei.

>  -George

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