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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 31 Mar 2015, George Dunlap wrote:
> On Mon, Mar 30, 2015 at 4:38 PM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> >> > 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.
> 
> It sounds like you're talking about introducing a hard dependency,
> such that packages that use a libxl built this way won't function
> without blktap installed.  Yeah, that's simple enough.
> 
> I'm not super experienced in the distro packaging mindset, but since
> (AFAIK) no other programs or projects use blktap, is there much point
> to having a separate repo if you can't "opt-out" of installing it?

It is not an hard dependency: as long as one doesn't use VHDs, ones
doesn't see any difference whether blktap is installed on not.


> >> #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.
> 
> My understanding was:
> 
> 1. The XenServer team develop and maintain blktap primarily for their
> own product.
> 
> 2. They don't have a particular desire for blktap to get wider usage.
> It's actually other projects -- CentOS and COLO in particular -- that
> want to be able to use a maintained version of blktap.
> 
> 3. The XenServer developers are, as individuals, happy to have other
> people using it; and are willing to make small amounts of efforts to
> be an "upstream" -- namely, accepting bug fixes and reviewing minor
> contributions.
> 
> 4. However, the XenServer team is primarily focused on building their
> own product. They won't be able to spend a significant amount of time
> making blktap more "community-friendly".  Adding features that are
> useful to other downstreams but not to XenServer will probably be
> accepted, but I wouldn't be surprised if large architectural changes
> which help downstreams (such as COLO) but don't have any benefit for
> XenServer were rejected.

In that case we should probably not have blktap in the xen-unstable
tree, because we wouldn't want to have so divergent community models
for different component in the same source repository.

However we could make it easier to built libxl and blktap together, we
could also add blktap to OSSTest and Raisin
(http://marc.info/?l=xen-devel&m=142779794216955).


> I figured it was worth giving it a try.  If things don't work out,
> then we can either fork (if someone is willing to maintain it), or
> remove blktap support entirely.


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