[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |