[PATCH 0/4] build enhancements related to qemu

[PATCH 0/4] build enhancements related to qemu

[Juergen Gross]

Last week I started an effort to use upstream qemu as a replacement
for qemu-trad in ioemu stubdom. This small series addresses some
problems I met in this effort. I believe all modifications are worth
doing regardless whether qemu upstream stubdom will become a reality
or not.

Juergen Gross (4):
  interface: avoid redefinition of __XEN_INTERFACE_VERSION__
  tools: add pkg-config file for libxc
  tools: use a dedicated build directory for qemu
  tools: set pkg-config path when configuring qemu

 .gitignore                      |  4 ++++
 stubdom/Makefile                |  2 ++
 tools/Makefile                  | 17 ++++++++++-------
 tools/Rules.mk                  | 13 +++++++++++++
 tools/libxc/Makefile            | 22 +++++++++++++++++++++-
 tools/libxc/xencontrol.pc.in    |  9 +++++++++
 xen/include/public/xen-compat.h |  1 +
 7 files changed, 60 insertions(+), 8 deletions(-)
 create mode 100644 tools/libxc/xencontrol.pc.in

-- 
2.10.2


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

[PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

[Juergen Gross]

In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined
on the command line of the build instruction. This conflicts with
xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__
is set.

Just use #undef in this case to avoid the resulting warning.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 xen/include/public/xen-compat.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
index b673653..9453439 100644
--- a/xen/include/public/xen-compat.h
+++ b/xen/include/public/xen-compat.h
@@ -31,6 +31,7 @@
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */
+#undef __XEN_INTERFACE_VERSION__
 #define __XEN_INTERFACE_VERSION__ __XEN_LATEST_INTERFACE_VERSION__
 #elif !defined(__XEN_INTERFACE_VERSION__)
 /* Guests which do not specify a version get the legacy interface. */
-- 
2.10.2


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

[PATCH 2/4] tools: add pkg-config file for libxc

[Juergen Gross]

When configuring the build of qemu the configure script is building
various test programs to determine the exact version of libxencontrol.

Instead of a try and error approach needing updates for nearly each
new version of Xen just provide xencontrol.pc to be used via
pkg-config.

In the end we need two different variants of that file: one for the
target system where eventually someone wants to build qemu, and one
for the local system to be used for building qemu as part of the Xen
build process.

The local variant is created in a dedicated directory in order to be
able to collect more pkg-config files used for building tools there.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 .gitignore                   |  3 +++
 stubdom/Makefile             |  2 ++
 tools/Makefile               |  3 ++-
 tools/Rules.mk               | 13 +++++++++++++
 tools/libxc/Makefile         | 22 +++++++++++++++++++++-
 tools/libxc/xencontrol.pc.in |  9 +++++++++
 6 files changed, 50 insertions(+), 2 deletions(-)
 create mode 100644 tools/libxc/xencontrol.pc.in

diff --git a/.gitignore b/.gitignore
index 557b38e..bd9ac53 100644
--- a/.gitignore
+++ b/.gitignore
@@ -79,6 +79,7 @@ stubdom/newlib-1.*
 stubdom/newlib-x86*
 stubdom/ocaml-*
 stubdom/pciutils-*
+stubdom/pkg-config/*
 stubdom/polarssl-*
 stubdom/stubdompath.sh
 stubdom/tpm_emulator-*
@@ -179,6 +180,7 @@ tools/include/xen/*
 tools/include/xen-xsm/*
 tools/include/xen-foreign/*.(c|h|size)
 tools/include/xen-foreign/checker
+tools/libxc/*.pc
 tools/libxl/_libxl.api-for-check
 tools/libxl/*.api-ok
 tools/libxl/*.pc
@@ -204,6 +206,7 @@ tools/misc/xen-hvmctx
 tools/misc/xenlockprof
 tools/misc/lowmemd
 tools/misc/xencov
+tools/pkg-config/*
 tools/xentrace/xenalyze
 tools/pygrub/build/*
 tools/python/build/*
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 39b81c9..c6458e8 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -318,6 +318,7 @@ define do_links
   cd $(dir $@); \
   ln -sf $(dir $<)include/*.h include/; \
   ln -sf $(dir $<)*.[ch] .; \
+  ln -sf $(dir $<)*.pc.in .; \
   ln -sf $(dir $<)Makefile .
   touch $@
 endef
@@ -623,6 +624,7 @@ clean:
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
 	rm -f *-minios-config.mk
+	rm -fr pkg-config
 	[ ! -e libs-$(XEN_TARGET_ARCH)/toollog/Makefile ] || $(MAKE) DESTDIR= -C libs-$(XEN_TARGET_ARCH)/toollog clean
 	[ ! -e libs-$(XEN_TARGET_ARCH)/evtchn/Makefile ] || $(MAKE) DESTDIR= -C libs-$(XEN_TARGET_ARCH)/evtchn clean
 	[ ! -e libs-$(XEN_TARGET_ARCH)/gnttab/Makefile ] || $(MAKE) DESTDIR= -C libs-$(XEN_TARGET_ARCH)/gnttab clean
diff --git a/tools/Makefile b/tools/Makefile
index 68633a4..9548ab4 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -111,9 +111,10 @@ uninstall:
 
 .PHONY: clean
 clean: subdirs-clean
+	rm -rf pkg-config
 
 .PHONY: distclean
-distclean: subdirs-distclean
+distclean: subdirs-distclean clean
 	rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote
 	rm -rf qemu-xen-dir qemu-xen-dir-remote
 	rm -rf ../config/Tools.mk config.h config.log config.status \
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 52bdd1a..e676c6b 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -245,3 +245,16 @@ ifeq (,$(findstring clean,$(MAKECMDGOALS)))
 $(XEN_ROOT)/config/Tools.mk:
 	$(error You have to run ./configure before building or installing the tools)
 endif
+
+$(PKG_CONFIG_DIR)/%.pc: %.pc.in Makefile
+	mkdir -p $(PKG_CONFIG_DIR)
+	@sed -e 's!@@version@@!$(PKG_CONFIG_VERSION)!g' \
+	     -e 's!@@prefix@@!$(PKG_CONFIG_PREFIX)!g' \
+	     -e 's!@@incdir@@!$(PKG_CONFIG_INCDIR)!g' \
+	     -e 's!@@libdir@@!$(PKG_CONFIG_LIBDIR)!g' < $< > $@
+
+%.pc: %.pc.in Makefile
+	@sed -e 's!@@version@@!$(PKG_CONFIG_VERSION)!g' \
+	     -e 's!@@prefix@@!$(PKG_CONFIG_PREFIX)!g' \
+	     -e 's!@@incdir@@!$(PKG_CONFIG_INCDIR)!g' \
+	     -e 's!@@libdir@@!$(PKG_CONFIG_LIBDIR)!g' < $< > $@
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index da689c4..a161ba7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -1,4 +1,5 @@
 XEN_ROOT = $(CURDIR)/../..
+PKG_CONFIG_DIR = ../pkg-config
 include $(XEN_ROOT)/tools/Rules.mk
 
 MAJOR    = 4.9
@@ -159,6 +160,22 @@ endif
 $(CTRL_LIB_OBJS) $(GUEST_LIB_OBJS) \
 $(CTRL_PIC_OBJS) $(GUEST_PIC_OBJS): xc_private.h
 
+PKG_CONFIG := xencontrol.pc
+PKG_CONFIG_VERSION := $(MAJOR).$(MINOR)
+
+ifneq ($(CONFIG_LIBXC_MINIOS),y)
+PKG_CONFIG_INST := $(PKG_CONFIG)
+$(PKG_CONFIG_INST): PKG_CONFIG_PREFIX = $(prefix)
+$(PKG_CONFIG_INST): PKG_CONFIG_INCDIR = $(includedir)
+$(PKG_CONFIG_INST): PKG_CONFIG_LIBDIR = $(libdir)
+endif
+
+PKG_CONFIG_LOCAL := $(foreach pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc))
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXC)/include
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
+
 .PHONY: all
 all: build
 
@@ -167,12 +184,13 @@ build:
 	$(MAKE) libs
 
 .PHONY: libs
-libs: $(LIB)
+libs: $(LIB) $(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL)
 
 .PHONY: install
 install: build
 	$(INSTALL_DIR) $(DESTDIR)$(libdir)
 	$(INSTALL_DIR) $(DESTDIR)$(includedir)
+	$(INSTALL_DIR) $(DESTDIR)$(PKG_INSTALLDIR)
 	$(INSTALL_SHLIB) libxenctrl.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir)
 	$(INSTALL_DATA) libxenctrl.a $(DESTDIR)$(libdir)
 	$(SYMLINK_SHLIB) libxenctrl.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir)/libxenctrl.so.$(MAJOR)
@@ -183,6 +201,7 @@ install: build
 	$(SYMLINK_SHLIB) libxenguest.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir)/libxenguest.so.$(MAJOR)
 	$(SYMLINK_SHLIB) libxenguest.so.$(MAJOR) $(DESTDIR)$(libdir)/libxenguest.so
 	$(INSTALL_DATA) include/xenguest.h $(DESTDIR)$(includedir)
+	$(INSTALL_DATA) xencontrol.pc $(DESTDIR)$(PKG_INSTALLDIR)
 
 .PHONY: TAGS
 TAGS:
@@ -192,6 +211,7 @@ TAGS:
 clean:
 	rm -rf *.rpm $(LIB) *~ $(DEPS) \
             _paths.h \
+	    xencontrol.pc \
             $(CTRL_LIB_OBJS) $(CTRL_PIC_OBJS) \
             $(GUEST_LIB_OBJS) $(GUEST_PIC_OBJS)
 
diff --git a/tools/libxc/xencontrol.pc.in b/tools/libxc/xencontrol.pc.in
new file mode 100644
index 0000000..213206f
--- /dev/null
+++ b/tools/libxc/xencontrol.pc.in
@@ -0,0 +1,9 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xencontrol
+Description: The Xencontrol library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir}
+Libs: -L${libdir} -lxenctrl
-- 
2.10.2


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

[PATCH 3/4] tools: use a dedicated build directory for qemu

[Juergen Gross]

Instead of using the downloaded git tree as target directory for the
qemu build create a dedicated directory for that purpose.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 .gitignore     |  1 +
 tools/Makefile | 13 +++++++------
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/.gitignore b/.gitignore
index bd9ac53..a4937f9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -207,6 +207,7 @@ tools/misc/xenlockprof
 tools/misc/lowmemd
 tools/misc/xencov
 tools/pkg-config/*
+tools/qemu-xen-build
 tools/xentrace/xenalyze
 tools/pygrub/build/*
 tools/python/build/*
diff --git a/tools/Makefile b/tools/Makefile
index 9548ab4..99080ab 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -116,7 +116,7 @@ clean: subdirs-clean
 .PHONY: distclean
 distclean: subdirs-distclean clean
 	rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote
-	rm -rf qemu-xen-dir qemu-xen-dir-remote
+	rm -rf qemu-xen-dir qemu-xen-dir-remote qemu-xen-build
 	rm -rf ../config/Tools.mk config.h config.log config.status \
 		config.cache autom4te.cache
 
@@ -244,9 +244,10 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
 	if test -d $(QEMU_UPSTREAM_LOC) ; then \
 		source=$(QEMU_UPSTREAM_LOC); \
 	else \
-		source=.; \
+		source=$(XEN_ROOT)/tools/qemu-xen-dir; \
 	fi; \
-	cd qemu-xen-dir; \
+	mkdir -p qemu-xen-build; \
+	cd qemu-xen-build; \
 	if $$source/scripts/tracetool.py --check-backend --backend log ; then \
 		enable_trace_backend='--enable-trace-backend=log'; \
 	elif $$source/scripts/tracetool.py --check-backend --backend stderr ; then \
@@ -299,12 +300,12 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
 	$(MAKE) all
 
 subdir-install-qemu-xen-dir: subdir-all-qemu-xen-dir
-	cd qemu-xen-dir; \
+	cd qemu-xen-build; \
 	$(MAKE) install
 
 subdir-clean-qemu-xen-dir:
-	set -e; if test -d qemu-xen-dir/.; then \
-		$(MAKE) -C qemu-xen-dir clean; \
+	set -e; if test -d qemu-xen-build/.; then \
+		$(MAKE) -C qemu-xen-build clean; \
 	fi
 
 subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony
-- 
2.10.2


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

[PATCH 4/4] tools: set pkg-config path when configuring qemu

[Juergen Gross]

When calling configure for qemu provide the local pkg-config directory
in order to let the configure process find the libxenctrl version.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 tools/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/Makefile b/tools/Makefile
index 99080ab..d6f8ce1 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -255,6 +255,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
 	else \
 		enable_trace_backend='' ; \
 	fi ; \
+	PKG_CONFIG_PATH=$(XEN_ROOT)/tools/pkg-config \
 	$$source/configure --enable-xen --target-list=i386-softmmu \
 		$(QEMU_XEN_ENABLE_DEBUG) \
 		$$enable_trace_backend \
-- 
2.10.2


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

Re: [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

[Andrew Cooper]

On 28/02/17 10:34, Juergen Gross wrote:
> In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined
> on the command line of the build instruction. This conflicts with
> xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__
> is set.
>
> Just use #undef in this case to avoid the resulting warning.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  xen/include/public/xen-compat.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
> index b673653..9453439 100644
> --- a/xen/include/public/xen-compat.h
> +++ b/xen/include/public/xen-compat.h
> @@ -31,6 +31,7 @@
>  
>  #if defined(__XEN__) || defined(__XEN_TOOLS__)
>  /* Xen is built with matching headers and implements the latest interface. */
> +#undef __XEN_INTERFACE_VERSION__
>  #define __XEN_INTERFACE_VERSION__ __XEN_LATEST_INTERFACE_VERSION__
>  #elif !defined(__XEN_INTERFACE_VERSION__)
>  /* Guests which do not specify a version get the legacy interface. */


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

Re: [PATCH 4/4] tools: set pkg-config path when configuring qemu

[Ian Jackson]

Juergen Gross writes ("[PATCH 4/4] tools: set pkg-config path when configuring qemu"):
> When calling configure for qemu provide the local pkg-config directory
> in order to let the configure process find the libxenctrl version.

Is PKG_CONFIG_PATH used _in addition to_ the built-in paths, or does
it replace them ?

Ian.

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

Re: [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

[Ian Jackson]

Juergen Gross writes ("[PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__"):
> In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined
> on the command line of the build instruction. This conflicts with
> xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__
> is set.

Aren't the two definitions the same ?  If so, surely there should be
no warning ?  If they are not the same, then surely we need to think
about which one is right ?

Sorry if the answers to this are obvious.

Thanks,
Ian.

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

Re: [PATCH 4/4] tools: set pkg-config path when configuring qemu

[Juergen Gross]

On 28/02/17 12:08, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 4/4] tools: set pkg-config path when configuring qemu"):
>> When calling configure for qemu provide the local pkg-config directory
>> in order to let the configure process find the libxenctrl version.
> 
> Is PKG_CONFIG_PATH used _in addition to_ the built-in paths, or does
> it replace them ?

It is in addition.


Juergen


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

Re: [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

[Jan Beulich]

>>> On 28.02.17 at 11:34, <JGross@suse.com> wrote:
> In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined
> on the command line of the build instruction. This conflicts with
> xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__
> is set.

Then that's what wants fixing. In fact it's questionable whether
__XEN_TOOLS__ (or even __XEN__) getting defined there is
appropriate.

> Just use #undef in this case to avoid the resulting warning.

I think the lack of a warning in case of a collision is worse here.
People should simply not define both the version symbol and
either of __XEN__ or __XEN_TOOLS__.

Jan


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

Re: [PATCH 2/4] tools: add pkg-config file for libxc

[Ian Jackson]

Juergen Gross writes ("[PATCH 2/4] tools: add pkg-config file for libxc"):
> When configuring the build of qemu the configure script is building
> various test programs to determine the exact version of libxencontrol.
> 
> Instead of a try and error approach needing updates for nearly each
> new version of Xen just provide xencontrol.pc to be used via
> pkg-config.
> 
> In the end we need two different variants of that file: one for the
> target system where eventually someone wants to build qemu, and one
> for the local system to be used for building qemu as part of the Xen
> build process.

I've not seen this done elsewhere, but I can see why it's attractive.
I worry though that we're breaking new ground.  Did you come up with
this idea yourself ?  Are you aware of other projects that do
something similar ?

Ian.

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

Re: [PATCH 3/4] tools: use a dedicated build directory for qemu

[Ian Jackson]

Juergen Gross writes ("[PATCH 3/4] tools: use a dedicated build directory for qemu"):
> Instead of using the downloaded git tree as target directory for the
> qemu build create a dedicated directory for that purpose.

... why ?

Ian.

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

Re: [PATCH 4/4] tools: set pkg-config path when configuring qemu

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH 4/4] tools: set pkg-config path when configuring qemu"):
> On 28/02/17 12:08, Ian Jackson wrote:
> > Is PKG_CONFIG_PATH used _in addition to_ the built-in paths, or does
> > it replace them ?
> 
> It is in addition.

Good.  Thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

Re: [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

[Juergen Gross]

On 28/02/17 12:11, Jan Beulich wrote:
>>>> On 28.02.17 at 11:34, <JGross@suse.com> wrote:
>> In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined
>> on the command line of the build instruction. This conflicts with
>> xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__
>> is set.
> 
> Then that's what wants fixing. In fact it's questionable whether
> __XEN_TOOLS__ (or even __XEN__) getting defined there is
> appropriate.

There are multiple libraries from the tools directory being compiled
for stubdoms.

>> Just use #undef in this case to avoid the resulting warning.
> 
> I think the lack of a warning in case of a collision is worse here.
> People should simply not define both the version symbol and
> either of __XEN__ or __XEN_TOOLS__.

Would you be okay with:

#if defined(__XEN_INTERFACE_VERSION__)
  #if __XEN_INTERFACE_VERSION__ != __XEN_LATEST_INTERFACE_VERSION__
    #error ...
  #endif
#else
  #define __XEN_INTERFACE_VERSION__ __XEN_LATEST_INTERFACE_VERSION__
#endif


Juergen

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

Re: [PATCH 2/4] tools: add pkg-config file for libxc

[Juergen Gross]

On 28/02/17 12:13, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 2/4] tools: add pkg-config file for libxc"):
>> When configuring the build of qemu the configure script is building
>> various test programs to determine the exact version of libxencontrol.
>>
>> Instead of a try and error approach needing updates for nearly each
>> new version of Xen just provide xencontrol.pc to be used via
>> pkg-config.
>>
>> In the end we need two different variants of that file: one for the
>> target system where eventually someone wants to build qemu, and one
>> for the local system to be used for building qemu as part of the Xen
>> build process.
> 
> I've not seen this done elsewhere, but I can see why it's attractive.

Thanks.

> I worry though that we're breaking new ground.  Did you come up with
> this idea yourself ?

Yes.

> Are you aware of other projects that do something similar ?

No.

TBH: did you have a look at qemu's configure script and how Xen support
is handled there? I'm really astonished they accept such a hackery.

And I don't see why it would be wrong to use the same basic mechanism
for our internal build as for any "normal" build outside of the Xen
build environment.

The next step would be to add the other Xen libraries and their
dependencies in order to get rid of all the additional include and
library directories when calling configure for qemu.


Juergen


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

Re: [PATCH 3/4] tools: use a dedicated build directory for qemu

[Juergen Gross]

On 28/02/17 12:13, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 3/4] tools: use a dedicated build directory for qemu"):
>> Instead of using the downloaded git tree as target directory for the
>> qemu build create a dedicated directory for that purpose.
> 
> ... why ?

Hmm, yes, I should have added the reason to the commit description:

This way I can use the same source directory of qemu for my effort to
configure and build qemu upstream in a stubdom environment.


Juergen


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

Re: [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

[Juergen Gross]

On 28/02/17 12:10, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__"):
>> In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined
>> on the command line of the build instruction. This conflicts with
>> xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__
>> is set.
> 
> Aren't the two definitions the same ?  If so, surely there should be
> no warning ?  If they are not the same, then surely we need to think
> about which one is right ?

In the end they are the same.

I don't know why the warning is issued. Maybe because one value was
specified via the command line.

> Sorry if the answers to this are obvious.

I think it isn't.


Juergen

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

Re: [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

[Jan Beulich]

>>> On 28.02.17 at 13:24, <JGross@suse.com> wrote:
> On 28/02/17 12:11, Jan Beulich wrote:
>>>>> On 28.02.17 at 11:34, <JGross@suse.com> wrote:
>>> In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined
>>> on the command line of the build instruction. This conflicts with
>>> xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__
>>> is set.
>> 
>> Then that's what wants fixing. In fact it's questionable whether
>> __XEN_TOOLS__ (or even __XEN__) getting defined there is
>> appropriate.
> 
> There are multiple libraries from the tools directory being compiled
> for stubdoms.

Each if which should get appropriate settings.

>>> Just use #undef in this case to avoid the resulting warning.
>> 
>> I think the lack of a warning in case of a collision is worse here.
>> People should simply not define both the version symbol and
>> either of __XEN__ or __XEN_TOOLS__.
> 
> Would you be okay with:
> 
> #if defined(__XEN_INTERFACE_VERSION__)
>   #if __XEN_INTERFACE_VERSION__ != __XEN_LATEST_INTERFACE_VERSION__
>     #error ...
>   #endif
> #else
>   #define __XEN_INTERFACE_VERSION__ __XEN_LATEST_INTERFACE_VERSION__
> #endif

Well - see Ian's reply. If the values match (granted textually rather
than by value), there should be no compiler warning in the first
place.

Jan


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

Re: [PATCH 2/4] tools: add pkg-config file for libxc

[Wei Liu]

On Tue, Feb 28, 2017 at 01:32:06PM +0100, Juergen Gross wrote:
> And I don't see why it would be wrong to use the same basic mechanism
> for our internal build as for any "normal" build outside of the Xen
> build environment.
> 

+1 for this.

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

Re: [PATCH 2/4] tools: add pkg-config file for libxc

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH 2/4] tools: add pkg-config file for libxc"):
> On 28/02/17 12:13, Ian Jackson wrote:
> > I worry though that we're breaking new ground.  Did you come up with
> > this idea yourself ?
> 
> Yes.

How exciting.

> > Are you aware of other projects that do something similar ?
> 
> No.

Well, anyway, my first impression is that this is a neat idea.  Would
you mind if I slept on it another day ?  If I can't think of a reason
not to do this by tomorrow I will ack your patch :-).

> TBH: did you have a look at qemu's configure script and how Xen support
> is handled there? I'm really astonished they accept such a hackery.

I dread to look.

> And I don't see why it would be wrong to use the same basic mechanism
> for our internal build as for any "normal" build outside of the Xen
> build environment.
> 
> The next step would be to add the other Xen libraries and their
> dependencies in order to get rid of all the additional include and
> library directories when calling configure for qemu.

Indeed.

Ian.

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

Re: [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

[Juergen Gross]

On 28/02/17 13:46, Jan Beulich wrote:
>>>> On 28.02.17 at 13:24, <JGross@suse.com> wrote:
>> On 28/02/17 12:11, Jan Beulich wrote:
>>>>>> On 28.02.17 at 11:34, <JGross@suse.com> wrote:
>>>> In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined
>>>> on the command line of the build instruction. This conflicts with
>>>> xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__
>>>> is set.
>>>
>>> Then that's what wants fixing. In fact it's questionable whether
>>> __XEN_TOOLS__ (or even __XEN__) getting defined there is
>>> appropriate.
>>
>> There are multiple libraries from the tools directory being compiled
>> for stubdoms.
> 
> Each if which should get appropriate settings.
> 
>>>> Just use #undef in this case to avoid the resulting warning.
>>>
>>> I think the lack of a warning in case of a collision is worse here.
>>> People should simply not define both the version symbol and
>>> either of __XEN__ or __XEN_TOOLS__.
>>
>> Would you be okay with:
>>
>> #if defined(__XEN_INTERFACE_VERSION__)
>>   #if __XEN_INTERFACE_VERSION__ != __XEN_LATEST_INTERFACE_VERSION__
>>     #error ...
>>   #endif
>> #else
>>   #define __XEN_INTERFACE_VERSION__ __XEN_LATEST_INTERFACE_VERSION__
>> #endif
> 
> Well - see Ian's reply. If the values match (granted textually rather
> than by value), there should be no compiler warning in the first
> place.

Hmm, maybe this is the problem: the value from the command line is
(textually) __XEN_LATEST_INTERFACE_VERSION__ while the value from the
#define is the _value_ of __XEN_LATEST_INTERFACE_VERSION__ due to the
pre-processor having replaced it already.

In case this makes sense, my suggestion seems to be appropriate, no?


Juergen


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

Re: [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

[Ian Jackson]

Juergen Gross writes ("Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__"):
> Hmm, maybe this is the problem: the value from the command line is
> (textually) __XEN_LATEST_INTERFACE_VERSION__ while the value from the
> #define is the _value_ of __XEN_LATEST_INTERFACE_VERSION__ due to the
> pre-processor having replaced it already.
> 
> In case this makes sense, my suggestion seems to be appropriate, no?

Maybe.  Another possibly would be to contrive to #define
__XEN_INTERFACE_VERSION__ before __XEN_LATEST_INTERFACE_VERSION__.
Then the second substitution would occur later.

Ian.

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

Re: [PATCH 3/4] tools: use a dedicated build directory for qemu

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH 3/4] tools: use a dedicated build directory for qemu"):
> On 28/02/17 12:13, Ian Jackson wrote:
> > ... why ?
> 
> Hmm, yes, I should have added the reason to the commit description:
> 
> This way I can use the same source directory of qemu for my effort to
> configure and build qemu upstream in a stubdom environment.

Great.  Can you put that (or something like it) in the commit message ?

With that change,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

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

Re: [PATCH 3/4] tools: use a dedicated build directory for qemu

[Juergen Gross]

On 28/02/17 14:14, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH 3/4] tools: use a dedicated build directory for qemu"):
>> On 28/02/17 12:13, Ian Jackson wrote:
>>> ... why ?
>>
>> Hmm, yes, I should have added the reason to the commit description:
>>
>> This way I can use the same source directory of qemu for my effort to
>> configure and build qemu upstream in a stubdom environment.
> 
> Great.  Can you put that (or something like it) in the commit message ?

Yes, I think I can manage that. :-)

> 
> With that change,
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 

Thanks,

Juergen

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

Re: [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

[Jan Beulich]

>>> On 28.02.17 at 14:10, <JGross@suse.com> wrote:
> On 28/02/17 13:46, Jan Beulich wrote:
>>>>> On 28.02.17 at 13:24, <JGross@suse.com> wrote:
>>> On 28/02/17 12:11, Jan Beulich wrote:
>>>>>>> On 28.02.17 at 11:34, <JGross@suse.com> wrote:
>>>>> In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined
>>>>> on the command line of the build instruction. This conflicts with
>>>>> xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__
>>>>> is set.
>>>>
>>>> Then that's what wants fixing. In fact it's questionable whether
>>>> __XEN_TOOLS__ (or even __XEN__) getting defined there is
>>>> appropriate.
>>>
>>> There are multiple libraries from the tools directory being compiled
>>> for stubdoms.
>> 
>> Each if which should get appropriate settings.
>> 
>>>>> Just use #undef in this case to avoid the resulting warning.
>>>>
>>>> I think the lack of a warning in case of a collision is worse here.
>>>> People should simply not define both the version symbol and
>>>> either of __XEN__ or __XEN_TOOLS__.
>>>
>>> Would you be okay with:
>>>
>>> #if defined(__XEN_INTERFACE_VERSION__)
>>>   #if __XEN_INTERFACE_VERSION__ != __XEN_LATEST_INTERFACE_VERSION__
>>>     #error ...
>>>   #endif
>>> #else
>>>   #define __XEN_INTERFACE_VERSION__ __XEN_LATEST_INTERFACE_VERSION__
>>> #endif
>> 
>> Well - see Ian's reply. If the values match (granted textually rather
>> than by value), there should be no compiler warning in the first
>> place.
> 
> Hmm, maybe this is the problem: the value from the command line is
> (textually) __XEN_LATEST_INTERFACE_VERSION__ while the value from the
> #define is the _value_ of __XEN_LATEST_INTERFACE_VERSION__ due to the
> pre-processor having replaced it already.

No, that replacement happens after having expanded
__XEN_INTERFACE_VERSION__ at use sites , not when
#define-ing it.

Jan


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

Re: [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

[Juergen Gross]

On 28/02/17 14:13, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__"):
>> Hmm, maybe this is the problem: the value from the command line is
>> (textually) __XEN_LATEST_INTERFACE_VERSION__ while the value from the
>> #define is the _value_ of __XEN_LATEST_INTERFACE_VERSION__ due to the
>> pre-processor having replaced it already.
>>
>> In case this makes sense, my suggestion seems to be appropriate, no?
> 
> Maybe.  Another possibly would be to contrive to #define
> __XEN_INTERFACE_VERSION__ before __XEN_LATEST_INTERFACE_VERSION__.
> Then the second substitution would occur later.

Please drop this patch.

Seems there are paths where __XEN_INTERFACE_VERSION__ is being set to
a different value.

The main problem seems to be that xenctrl.h #define's __XEN_TOOLS__
in order to get all structures of #include'd headers, but it isn't
#undef'ining it at the end.

I believe all stubdoms using xenctrl.h in their main app should
explicitly set __XEN_INTERFACE_VERSION__ in their config file to
__XEN_LATEST_INTERFACE_VERSION__.

I'll send a patch doing this.


Juergen


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