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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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?

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

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.

 -George

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