Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On Tue, 2015-03-31 at 12:10 +0100, George Dunlap wrote: > On 03/31/2015 11:40 AM, Stefano Stabellini wrote: > > On Tue, 31 Mar 2015, George Dunlap wrote: > >> On Mon, Mar 30, 2015 at 4:38 PM, Wei Liu 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. > > I'm talking about a hard dependency *for the resulting package*. > > If libxl built linked against libblktap, and libblktap is not installed > on the system, then won't running the binary at all result in "Can't > find shared library" errors? > > In any case, I'm pretty sure that if you build an RPM and link against a > particular library, that the RPM will then refuse to install if that > library isn't available. Correct (for Debian too), but this is more about the RPM maintainers freedom to choose to enable it or not. Once they chosen their users will just end up with whatever they chose. For arch and gentoo folks I suppose this would be a USE var or whatever they call it. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On Tue, 2015-03-31 at 12:10 +0100, George Dunlap wrote: > > 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 wouldn't mind moving all external repos (qemu-*, seabios, ovmf, > blktap, &c) out of the Xen tree as soon as Raisin is mature enough to do so. Given the intertwining of blktap2 with libxl etc making it a cloned-by-xen.git tree instead of in-xen.git might be a convenient first step? The raisin development would then proceed using the --with-system-blktap option and eventually the in tree stuff could be dropped. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On 03/31/2015 11:40 AM, Stefano Stabellini wrote: > On Tue, 31 Mar 2015, George Dunlap wrote: >> On Mon, Mar 30, 2015 at 4:38 PM, Wei Liu 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. I'm talking about a hard dependency *for the resulting package*. If libxl built linked against libblktap, and libblktap is not installed on the system, then won't running the binary at all result in "Can't find shared library" errors? In any case, I'm pretty sure that if you build an RPM and link against a particular library, that the RPM will then refuse to install if that library isn't available. > 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. Community model doesn't matter to me; what matters to me is the practical question of whether we can upstream what we need to upstream. An upstream that was in theory open but in practice difficult to work with or hostile to our patches would be a lot worse than an upstream that was in theory closed but in practice cooperative and took everything we sent them. I don't expect there to be any major changes required upstream, and so I think that in practice this won't be an issue. If it ever does become an issue, then we can decide what to do about it at that time. The reason I put it so strongly is that I want to make sure that there are no hard feelings if we end up having to go separate ways. The XenServer team are doing us a favor, and haven't promised a large amount of development time or commitment. I think what they're willing to offer will be sufficient for what we need. > 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 wouldn't mind moving all external repos (qemu-*, seabios, ovmf, blktap, &c) out of the Xen tree as soon as Raisin is mature enough to do so. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On Tue, 31 Mar 2015, George Dunlap wrote: > On Mon, Mar 30, 2015 at 4:38 PM, Wei Liu 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@lists.xen.org http://lists.xen.org/xen-devel
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 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@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
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 +, 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. > 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@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On 30/03/15 15:41, Ian Campbell wrote: > On Mon, 2015-03-30 at 15:33 +0100, Wei Liu wrote: >> On Thu, Mar 26, 2015 at 12:46:08PM +, 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 think you are right, there are at least some distros which ship a > blktap package not from Xen. e.g. Debian ship, or have in the past > shipped, the blktap2.5 packages. > > blktap is a bit different to some of the other similar cases though in > that there is a circular dependency, although George indicated last week > that he thought that might be an easily fixed one. I seem to recall that some bits of blktap need xen-devel (depending on exactly what is built). libxl will need blktap-devel, so these dependences can be resolved. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On 03/30/2015 03:41 PM, Ian Campbell wrote: > On Mon, 2015-03-30 at 15:33 +0100, Wei Liu wrote: >> On Thu, Mar 26, 2015 at 12:46:08PM +, 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 think you are right, there are at least some distros which ship a > blktap package not from Xen. e.g. Debian ship, or have in the past > shipped, the blktap2.5 packages. Bob has said that Fedora ship a blktap2.5 package that can't actually be installed at the same time as the Fedora xen packages, making it somewhat useless... > blktap is a bit different to some of the other similar cases though in > that there is a circular dependency, although George indicated last week > that he thought that might be an easily fixed one. I suspect this has probably already been fixed in blktap2.5, since (I'm pretty sure) XenServer ship blktap and the things that depend on it (like xen and xapi) in separate rpms; but it's certainly something we'd have to look at. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On 03/30/2015 03:33 PM, Wei Liu wrote: > On Thu, Mar 26, 2015 at 12:46:08PM +, 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On Mon, 2015-03-30 at 15:33 +0100, Wei Liu wrote: > On Thu, Mar 26, 2015 at 12:46:08PM +, 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 think you are right, there are at least some distros which ship a blktap package not from Xen. e.g. Debian ship, or have in the past shipped, the blktap2.5 packages. blktap is a bit different to some of the other similar cases though in that there is a circular dependency, although George indicated last week that he thought that might be an easily fixed one. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On Thu, Mar 26, 2015 at 12:46:08PM +, 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. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On Thu, Mar 26, 2015 at 12:55 PM, Ian Campbell wrote: > On Thu, 2015-03-26 at 12:46 +, George Dunlap wrote: > > Typo in $subject. > >> 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. > > We would also need to decide whether to have a push gate or not (I think > we should) and whether to track a branch automatically or manually > update the revision (I don't know, depends). I think ideally we'd track the "blktap2" branch during normal development, and grab a specific commit ID when we go into feature freeze. But at the moment, that only works if I put "origin/blktap2" in the REVISION, which doesn't seem quite right. On my to-do list is making the git checkout capable of looking for remote branches. (AFAICT "master" works because a local branch called "master" is made by default on checkout.) -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
On Thu, 2015-03-26 at 12:46 +, George Dunlap wrote: Typo in $subject. > 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. We would also need to decide whether to have a push gate or not (I think we should) and whether to track a branch automatically or manually update the revision (I don't know, depends). Either way I think osstest needs to learn a bit about blktap2. Overall I'm in favour of the general idea of this change though. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
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. CC: Ian Campbell CC: Ian Jackson CC: Wei Liu CC: Dave Scott CC: Jonathan Ludlam CC: Wen Congyang CC: Yang Hongyang --- .gitignore | 3 +++ Config.mk| 9 + tools/Makefile | 49 + tools/misc/mktarball | 2 ++ 4 files changed, 63 insertions(+) diff --git a/.gitignore b/.gitignore index c6185a0..1bc9602 100644 --- a/.gitignore +++ b/.gitignore @@ -261,6 +261,9 @@ tools/qemu-xen-dir tools/qemu-xen-traditional-dir-remote tools/qemu-xen-traditional-dir +tools/blktap-dir-remote +tools/blktap-dir + tools/firmware/seabios-dir-remote tools/firmware/seabios-dir diff --git a/Config.mk b/Config.mk index b243fac..7359763 100644 --- a/Config.mk +++ b/Config.mk @@ -224,6 +224,7 @@ XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles # Where to look for inlined subtrees (for example, from a tarball) QEMU_UPSTREAM_INTREE ?= $(XEN_ROOT)/tools/qemu-xen QEMU_TRADITIONAL_INTREE ?= $(XEN_ROOT)/tools/qemu-xen-traditional +BLKTAP_UPSTREAM_INTREE ?= $(XEN_ROOT)/tools/blktap # Handle legacy options @@ -240,19 +241,24 @@ ifneq (,$(QEMU_TAG)) QEMU_TRADITIONAL_REVISION ?= $(QEMU_TAG) endif +# FIXME +BLKTAP_UPSTREAM_URL ?= https://github.com/xapi-project/blktap.git ifeq ($(GIT_HTTP),y) OVMF_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/ovmf.git QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-unstable.git QEMU_TRADITIONAL_URL ?= http://xenbits.xen.org/git-http/qemu-xen-unstable.git SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git MINIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/mini-os.git +BLKTAP_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/blktap.git else OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xen-unstable.git SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git +BLKTAP_UPSTREAM_URL ?= git://xenbits.xen.org/blktap.git endif +BLKTAP_UPSTREAM_REVISION ?= d73c74874a449c18dc1528076e5c0671cc5ed409 OVMF_UPSTREAM_REVISION ?= a065efc7c7ce8bb3e5cb3e463099d023d4a92927 QEMU_UPSTREAM_REVISION ?= master MINIOS_UPSTREAM_REVISION ?= edfd5aae6ec5ba7d0a8834a3e9dfe5e69424150a @@ -281,6 +287,9 @@ QEMU_TRADITIONAL_LOC ?= $(call or,$(wildcard $(QEMU_TRADITIONAL_INTREE)),\ QEMU_UPSTREAM_LOC ?= $(call or,$(wildcard $(QEMU_UPSTREAM_INTREE)),\ $(QEMU_UPSTREAM_URL)) +BLKTAP_UPSTREAM_LOC ?= $(call or,$(wildcard $(BLKTAP_UPSTREAM_INTREE)),\ + $(BLKTAP_UPSTREAM_URL)) + # Short answer -- do not enable this unless you know what you are # doing and are prepared for some pain. diff --git a/tools/Makefile b/tools/Makefile index 966354a..b0b2a02 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -25,6 +25,7 @@ SUBDIRS-$(CONFIG_Linux) += libvchan ifneq "$(MAKECMDGOALS)" "distclean" SUBDIRS-$(CONFIG_QEMU_TRAD) += qemu-xen-traditional-dir SUBDIRS-$(CONFIG_QEMU_XEN) += qemu-xen-dir +SUBDIRS-$(CONFIG_BLKTAP2) += blktap-dir endif SUBDIRS-y += xenpmd @@ -108,6 +109,7 @@ clean: subdirs-clean distclean: subdirs-distclean rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote rm -rf qemu-xen-dir qemu-xen-dir-remote + rm -rf blktap-dir blktap-dir-remote rm -rf ../config/Tools.mk config.h config.log config.status \ config.cache autom4te.cache @@ -276,6 +278,49 @@ subdir-clean-qemu-xen-dir: $(MAKE) -C qemu-xen-dir clean; \ fi +# External target: blktap +blktap-dir-find: + if test -d $(BLKTAP_UPSTREAM_LOC) ; then \ + mkdir -p blktap-dir; \ + else \ + export GIT=$(GIT); \ + $(XEN_ROOT)/scripts/git-checkout.sh $(BLKTAP_UPSTREAM_LOC) $(BLKTAP_UPSTREAM_REVISION) blktap-dir ; \ + fi + +.PHONY: blktap-dir-force-update +blktap-dir-force-update: blktap-dir-find + set -ex; \ + if [ "$(BLKTAP_UPSTREAM_REVISION)" ]; then \ + cd blktap-dir-remote; \ + $(GIT) fetch origin; \ + $(GIT) reset --hard $(BLKTAP_UPSTREAM_REVISION); \ + fi + +subdir-all-blktap-dir: blktap-dir-find + if test -d $(BLKTAP_UPSTREAM_LOC) ; then \ + source=$(BLKTAP_UPSTREAM_LOC); \ + else \ + source=.; \ + fi; \ + cd blktap-dir; \ + $$source/autogen.sh ; \ + $$source/configure --prefix=$(PREFIX) \ + --libdir=$(LIBDIR) \ +
