[PATCH 0/6] tools/include: adjustments to the population of xen/

[PATCH 0/6] tools/include: adjustments to the population of xen/

[Jan Beulich]

While looking at what it would take to move around libelf/
in the hypervisor subtree, I've run into this rule, which I
think can do with a few improvements and some simplification.

1: adjust population of acpi/
2: fix (drop) dependencies of when to populate xen/
3: adjust population of public headers into xen/
4: properly install Arm public headers
5: adjust x86-specific population of xen/
6: drop remaining -f from ln invocations

Jan

[PATCH 1/6] tools/include: adjust population of acpi/

[Jan Beulich]

Limit what gets exposed - in particular cpufreq/ and apei.h are
hypervisor private headers which the tool stack building shouldn't see
or use. Also don't pass -f to ln, to allow noticing name collisions
right away.

Additionally acpi/ also has been in need of deleting at the start of
the rule, or alternatively the respective ln would have needed to also
be passed -n.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -16,15 +16,16 @@ XEN_PUBLIC_INCLUDES = $(wildcard $(XEN_R
 XEN_LIB_X86_INCLUDES = $(filter-out %autogen.h, $(XEN_ROOT)/xen/include/xen/lib/x86/Makefile $(wildcard $(XEN_ROOT)/xen/include/xen/lib/x86/*.h))
 
 xen/.dir: $(XEN_PUBLIC_INCLUDES) $(XEN_LIB_X86_INCLUDES)
-	@rm -rf xen
-	mkdir -p xen/libelf
+	@rm -rf xen acpi
+	mkdir -p xen/libelf acpi
 	ln -sf $(XEN_ROOT)/xen/include/public/COPYING xen
 	ln -sf $(XEN_PUBLIC_INCLUDES) xen
 	ln -sf $(addprefix $(XEN_ROOT)/xen/include/public/,arch-x86 arch-arm hvm io xsm) xen
 	ln -sf ../xen-sys/$(XEN_OS) xen/sys
 	ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/
 	ln -s ../xen-foreign xen/foreign
-	ln -sf $(XEN_ROOT)/xen/include/acpi acpi
+	ln -s $(XEN_ROOT)/xen/include/acpi/platform acpi/
+	ln -s $(XEN_ROOT)/xen/include/acpi/ac*.h acpi/
 ifeq ($(CONFIG_X86),y)
 	ln -sf $(XEN_ROOT)/xen/include/asm-x86 xen/asm
 	mkdir -p xen/lib/x86

[PATCH 2/6] tools/include: fix (drop) dependencies of when to populate xen/

[Jan Beulich]

Making the population of xen/ depend on the time stamps of a subset of
the headers put there is error prone. The creation of a few dozen
symlinks doesn't take a meaningful amount of time (compared to the
overall building of tools/), and hence - to be on the safe side - should
simply be done always. Convert the goal to a phony one and drop its
dependencies, effectively taking further what 8d8d7d6b3dc1 ("tools: fix
linking hypervisor includes to tools include directory") had already
attempted.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -4,8 +4,8 @@ include $(XEN_ROOT)/tools/Rules.mk
 # Relative to $(XEN_ROOT)/xen/xsm/flask
 FLASK_H_DEPEND := policy/initial_sids
 
-.PHONY: all all-y build
-all build: all-y xen-foreign xen/.dir xen-xsm/.dir
+.PHONY: all all-y build xen-dir
+all build: all-y xen-foreign xen-dir xen-xsm/.dir
 all-y:
 
 .PHONY: xen-foreign
@@ -15,7 +15,7 @@ xen-foreign:
 XEN_PUBLIC_INCLUDES = $(wildcard $(XEN_ROOT)/xen/include/public/*.h)
 XEN_LIB_X86_INCLUDES = $(filter-out %autogen.h, $(XEN_ROOT)/xen/include/xen/lib/x86/Makefile $(wildcard $(XEN_ROOT)/xen/include/xen/lib/x86/*.h))
 
-xen/.dir: $(XEN_PUBLIC_INCLUDES) $(XEN_LIB_X86_INCLUDES)
+xen-dir:
 	@rm -rf xen acpi
 	mkdir -p xen/libelf acpi
 	ln -sf $(XEN_ROOT)/xen/include/public/COPYING xen
@@ -33,9 +33,8 @@ ifeq ($(CONFIG_X86),y)
 		ln -sf $(XEN_ROOT)/xen/include/xen/lib/x86/$$f xen/lib/x86/$$f; \
 	done
 endif
-	touch $@
 
-all-$(CONFIG_X86): xen/.dir
+all-$(CONFIG_X86): xen-dir
 	$(MAKE) -C xen/lib/x86 all XEN_ROOT=$(XEN_ROOT) PYTHON=$(PYTHON)
 
 # Not xen/xsm as that clashes with link to

[PATCH 3/6] tools/include: adjust population of public headers into xen/

[Jan Beulich]

Use a wildcard also for the subdirectories, drop XEN_PUBLIC_INCLUDES for
having a single use only, and don't pass -f to ln to allow noticing name
collisions right away, and add trailing slashes to ln's destination.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -12,15 +12,14 @@ all-y:
 xen-foreign:
 	$(MAKE) -C xen-foreign
 
-XEN_PUBLIC_INCLUDES = $(wildcard $(XEN_ROOT)/xen/include/public/*.h)
 XEN_LIB_X86_INCLUDES = $(filter-out %autogen.h, $(XEN_ROOT)/xen/include/xen/lib/x86/Makefile $(wildcard $(XEN_ROOT)/xen/include/xen/lib/x86/*.h))
 
 xen-dir:
 	@rm -rf xen acpi
 	mkdir -p xen/libelf acpi
-	ln -sf $(XEN_ROOT)/xen/include/public/COPYING xen
-	ln -sf $(XEN_PUBLIC_INCLUDES) xen
-	ln -sf $(addprefix $(XEN_ROOT)/xen/include/public/,arch-x86 arch-arm hvm io xsm) xen
+	ln -s $(XEN_ROOT)/xen/include/public/COPYING xen/
+	ln -s $(XEN_ROOT)/xen/include/public/*.h xen/
+	ln -s $(XEN_ROOT)/xen/include/public/*/ xen/
 	ln -sf ../xen-sys/$(XEN_OS) xen/sys
 	ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/
 	ln -s ../xen-foreign xen/foreign

[PATCH 4/6] tools/include: properly install Arm public headers

[Jan Beulich]

When smccc.h was added, adjustment of the install rule was missed.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -60,10 +60,7 @@ install: all
 	$(INSTALL_DATA) xen/*.h $(DESTDIR)$(includedir)/xen
 	$(INSTALL_DATA) xen/arch-x86/*.h $(DESTDIR)$(includedir)/xen/arch-x86
 	$(INSTALL_DATA) xen/arch-x86/hvm/*.h $(DESTDIR)$(includedir)/xen/arch-x86/hvm
-
-# 	xen/arch-arm doesn't contains headers for now. Uncommented the line
-# 	as soon as a new header is added
-#	$(INSTALL_DATA) xen/arch-arm/*.h $(DESTDIR)$(includedir)/xen/arch-arm
+	$(INSTALL_DATA) xen/arch-arm/*.h $(DESTDIR)$(includedir)/xen/arch-arm
 	$(INSTALL_DATA) xen/arch-arm/hvm/*.h $(DESTDIR)$(includedir)/xen/arch-arm/hvm
 	$(INSTALL_DATA) xen/foreign/*.h $(DESTDIR)$(includedir)/xen/foreign
 	$(INSTALL_DATA) xen/hvm/*.h $(DESTDIR)$(includedir)/xen/hvm

[PATCH 5/6] tools/include: adjust x86-specific population of xen/

[Jan Beulich]

There's no need to use a shell loop construct here - ln's destination
can be specified as just the intended directory, as we don't mean to
change the names of any of the files. Also drop XEN_LIB_X86_INCLUDES for
having a single use only, and don't pass -f to ln, to allow noticing
name collisions right away.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -12,8 +12,6 @@ all-y:
 xen-foreign:
 	$(MAKE) -C xen-foreign
 
-XEN_LIB_X86_INCLUDES = $(filter-out %autogen.h, $(XEN_ROOT)/xen/include/xen/lib/x86/Makefile $(wildcard $(XEN_ROOT)/xen/include/xen/lib/x86/*.h))
-
 xen-dir:
 	@rm -rf xen acpi
 	mkdir -p xen/libelf acpi
@@ -26,11 +24,10 @@ xen-dir:
 	ln -s $(XEN_ROOT)/xen/include/acpi/platform acpi/
 	ln -s $(XEN_ROOT)/xen/include/acpi/ac*.h acpi/
 ifeq ($(CONFIG_X86),y)
-	ln -sf $(XEN_ROOT)/xen/include/asm-x86 xen/asm
+	ln -s $(XEN_ROOT)/xen/include/asm-x86 xen/asm
 	mkdir -p xen/lib/x86
-	for f in $(patsubst $(XEN_ROOT)/xen/include/xen/lib/x86/%,%,$(XEN_LIB_X86_INCLUDES)); do \
-		ln -sf $(XEN_ROOT)/xen/include/xen/lib/x86/$$f xen/lib/x86/$$f; \
-	done
+	ln -s $(filter-out %autogen.h,$(wildcard $(XEN_ROOT)/xen/include/xen/lib/x86/*.h)) xen/lib/x86/
+	ln -s $(XEN_ROOT)/xen/include/xen/lib/x86/Makefile xen/lib/x86/
 endif
 
 all-$(CONFIG_X86): xen-dir

[PATCH 6/6] tools/include: drop remaining -f from ln invocations

[Jan Beulich]

This is once again to allow noticing name collisions right away.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -18,8 +18,8 @@ xen-dir:
 	ln -s $(XEN_ROOT)/xen/include/public/COPYING xen/
 	ln -s $(XEN_ROOT)/xen/include/public/*.h xen/
 	ln -s $(XEN_ROOT)/xen/include/public/*/ xen/
-	ln -sf ../xen-sys/$(XEN_OS) xen/sys
-	ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/
+	ln -s ../xen-sys/$(XEN_OS) xen/sys
+	ln -s $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/
 	ln -s ../xen-foreign xen/foreign
 	ln -s $(XEN_ROOT)/xen/include/acpi/platform acpi/
 	ln -s $(XEN_ROOT)/xen/include/acpi/ac*.h acpi/

Re: [PATCH 0/6] tools/include: adjustments to the population of xen/

[Andrew Cooper]

On 10/09/2020 13:09, Jan Beulich wrote:
> While looking at what it would take to move around libelf/
> in the hypervisor subtree, I've run into this rule, which I
> think can do with a few improvements and some simplification.

I realise this might be a controversial move, but can we *please*
address this by removing our use of symlinking, rather than kicking the
problem down the road.

For header files in particular, there is no need to symlink at all. 
Some properly formed -I runes for the compiler will do the right thing,
and avoid all intermediate regeneration issues.

~Andrew

Re: [PATCH 0/6] tools/include: adjustments to the population of xen/

[Jürgen Groß]

On 10.09.20 15:51, Andrew Cooper wrote:
> On 10/09/2020 13:09, Jan Beulich wrote:
>> While looking at what it would take to move around libelf/
>> in the hypervisor subtree, I've run into this rule, which I
>> think can do with a few improvements and some simplification.
> 
> I realise this might be a controversial move, but can we *please*
> address this by removing our use of symlinking, rather than kicking the
> problem down the road.
> 
> For header files in particular, there is no need to symlink at all.
> Some properly formed -I runes for the compiler will do the right thing,
> and avoid all intermediate regeneration issues.

This is true only if all headers in a directory are to be shared.
Otherwise you might end up with including a file with a name collision
which happens to be in a directory you now specify via -I

I'm not opposed to your proposal, but this should be accompanied by a
clean header directory structure (all or no headers in a directory meant
to be shared).


Juergen

Re: [PATCH 0/6] tools/include: adjustments to the population of xen/

[Jan Beulich]

On 10.09.2020 15:51, Andrew Cooper wrote:
> On 10/09/2020 13:09, Jan Beulich wrote:
>> While looking at what it would take to move around libelf/
>> in the hypervisor subtree, I've run into this rule, which I
>> think can do with a few improvements and some simplification.
> 
> I realise this might be a controversial move, but can we *please*
> address this by removing our use of symlinking, rather than kicking the
> problem down the road.
> 
> For header files in particular, there is no need to symlink at all. 
> Some properly formed -I runes for the compiler will do the right thing,
> and avoid all intermediate regeneration issues.

With some further work to separate headers in e.g. Xen's acpi/
into ones to be exposed and ones not to be exposed, this
would likely be an option. It's not clear to me though how you
mean to deal with libelf.h and elfstructs.h. Nor is it clear
how we'd deal with x86's cpuid-autogen.h, which needs to have
distinct instances in the two subtrees.

And of course the present full exposure of asm-x86 rather wants
limiting than setting in stone by using -I to point into the
hypervisor tree.

Installing of the headers into dist/ will also need re-working
then.

Taking things together - no, I don't think I'm up to doing this,
yet I think the series presented is an improvement.

Jan

Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/

[Jan Beulich]

On 10.09.2020 14:09, Jan Beulich wrote:
> While looking at what it would take to move around libelf/
> in the hypervisor subtree, I've run into this rule, which I
> think can do with a few improvements and some simplification.
> 
> 1: adjust population of acpi/
> 2: fix (drop) dependencies of when to populate xen/
> 3: adjust population of public headers into xen/
> 4: properly install Arm public headers
> 5: adjust x86-specific population of xen/
> 6: drop remaining -f from ln invocations

While Andrew did voice some objection to symlinking in general,
in reply I've clarified I'm not up to the work involved to doing
so in cleanly enough a way. I'd therefore like to ask that either
this series be considered for putting in, or that it be made
clear how else the issues addressed here are going to be dealt
with (and by whom and when).

Thanks, Jan

Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/

[Jan Beulich]

On 10.09.2020 14:09, Jan Beulich wrote:
> While looking at what it would take to move around libelf/
> in the hypervisor subtree, I've run into this rule, which I
> think can do with a few improvements and some simplification.
> 
> 1: adjust population of acpi/
> 2: fix (drop) dependencies of when to populate xen/
> 3: adjust population of public headers into xen/
> 4: properly install Arm public headers
> 5: adjust x86-specific population of xen/
> 6: drop remaining -f from ln invocations

May I ask for an ack or otherwise here?

Thanks, Jan

Re: Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/

[Bertrand Marquis]

Hi Jan,

> On 1 Oct 2020, at 17:03, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 10.09.2020 14:09, Jan Beulich wrote:
>> While looking at what it would take to move around libelf/
>> in the hypervisor subtree, I've run into this rule, which I
>> think can do with a few improvements and some simplification.
>> 
>> 1: adjust population of acpi/
>> 2: fix (drop) dependencies of when to populate xen/
>> 3: adjust population of public headers into xen/
>> 4: properly install Arm public headers
>> 5: adjust x86-specific population of xen/
>> 6: drop remaining -f from ln invocations
> 
> May I ask for an ack or otherwise here?

This is going the right way but with this serie (on top of current staging
status), I have a compilation error in Yocto while compiling qemu:
 In file included from /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/recipe-sysroot/usr/include/xenguest.h:25,
|                  from /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/qemu-5.1.0/hw/i386/xen/xen_platform.c:41:
| /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/recipe-sysroot/usr/include/xenctrl_dom.h:19:10: fatal error: xen/libelf/libelf.h: No such file or directory
|    19 | #include <xen/libelf/libelf.h>
|       |          ^~~~~~~~~~~~~~~~~~~~~
| compilation terminated.
| /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/qemu-5.1.0/rules.mak:69: recipe for target 'hw/i386/xen/xen_platform.o’ failed

Xen is using xenctrl_dom.h which need the libelf.h header from xen.

Regards
Bertrand

Re: Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/

[Bertrand Marquis]

Hi,

> On 1 Oct 2020, at 17:29, Bertrand Marquis <bertrand.marquis@arm.com> wrote:
> 
> Hi Jan,
> 
>> On 1 Oct 2020, at 17:03, Jan Beulich <jbeulich@suse.com> wrote:
>> 
>> On 10.09.2020 14:09, Jan Beulich wrote:
>>> While looking at what it would take to move around libelf/
>>> in the hypervisor subtree, I've run into this rule, which I
>>> think can do with a few improvements and some simplification.
>>> 
>>> 1: adjust population of acpi/
>>> 2: fix (drop) dependencies of when to populate xen/
>>> 3: adjust population of public headers into xen/
>>> 4: properly install Arm public headers
>>> 5: adjust x86-specific population of xen/
>>> 6: drop remaining -f from ln invocations
>> 
>> May I ask for an ack or otherwise here?
> 
> This is going the right way but with this serie (on top of current staging
> status), I have a compilation error in Yocto while compiling qemu:
> In file included from /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/recipe-sysroot/usr/include/xenguest.h:25,
> |                  from /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/qemu-5.1.0/hw/i386/xen/xen_platform.c:41:
> | /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/recipe-sysroot/usr/include/xenctrl_dom.h:19:10: fatal error: xen/libelf/libelf.h: No such file or directory
> |    19 | #include <xen/libelf/libelf.h>
> |       |          ^~~~~~~~~~~~~~~~~~~~~
> | compilation terminated.
> | /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/qemu-5.1.0/rules.mak:69: recipe for target 'hw/i386/xen/xen_platform.o’ failed
> 
> Xen is using xenctrl_dom.h which need the libelf.h header from xen.

Actually this is not coming from your serie and this is actually a problem already present on master.

Regards
Bertrand

Re: Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/

[Jürgen Groß]

On 01.10.20 18:43, Bertrand Marquis wrote:
> Hi,
> 
>> On 1 Oct 2020, at 17:29, Bertrand Marquis <bertrand.marquis@arm.com> wrote:
>>
>> Hi Jan,
>>
>>> On 1 Oct 2020, at 17:03, Jan Beulich <jbeulich@suse.com> wrote:
>>>
>>> On 10.09.2020 14:09, Jan Beulich wrote:
>>>> While looking at what it would take to move around libelf/
>>>> in the hypervisor subtree, I've run into this rule, which I
>>>> think can do with a few improvements and some simplification.
>>>>
>>>> 1: adjust population of acpi/
>>>> 2: fix (drop) dependencies of when to populate xen/
>>>> 3: adjust population of public headers into xen/
>>>> 4: properly install Arm public headers
>>>> 5: adjust x86-specific population of xen/
>>>> 6: drop remaining -f from ln invocations
>>>
>>> May I ask for an ack or otherwise here?
>>
>> This is going the right way but with this serie (on top of current staging
>> status), I have a compilation error in Yocto while compiling qemu:
>> In file included from /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/recipe-sysroot/usr/include/xenguest.h:25,
>> |                  from /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/qemu-5.1.0/hw/i386/xen/xen_platform.c:41:
>> | /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/recipe-sysroot/usr/include/xenctrl_dom.h:19:10: fatal error: xen/libelf/libelf.h: No such file or directory
>> |    19 | #include <xen/libelf/libelf.h>
>> |       |          ^~~~~~~~~~~~~~~~~~~~~
>> | compilation terminated.
>> | /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/qemu-5.1.0/rules.mak:69: recipe for target 'hw/i386/xen/xen_platform.o’ failed
>>
>> Xen is using xenctrl_dom.h which need the libelf.h header from xen.
> 
> Actually this is not coming from your serie and this is actually a problem already present on master.

... and fixed on staging.


Juergen

Re: Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/

[Bertrand Marquis]

> On 2 Oct 2020, at 05:27, Jürgen Groß <jgross@suse.com> wrote:
> 
> On 01.10.20 18:43, Bertrand Marquis wrote:
>> Hi,
>>> On 1 Oct 2020, at 17:29, Bertrand Marquis <bertrand.marquis@arm.com> wrote:
>>> 
>>> Hi Jan,
>>> 
>>>> On 1 Oct 2020, at 17:03, Jan Beulich <jbeulich@suse.com> wrote:
>>>> 
>>>> On 10.09.2020 14:09, Jan Beulich wrote:
>>>>> While looking at what it would take to move around libelf/
>>>>> in the hypervisor subtree, I've run into this rule, which I
>>>>> think can do with a few improvements and some simplification.
>>>>> 
>>>>> 1: adjust population of acpi/
>>>>> 2: fix (drop) dependencies of when to populate xen/
>>>>> 3: adjust population of public headers into xen/
>>>>> 4: properly install Arm public headers
>>>>> 5: adjust x86-specific population of xen/
>>>>> 6: drop remaining -f from ln invocations
>>>> 
>>>> May I ask for an ack or otherwise here?
>>> 
>>> This is going the right way but with this serie (on top of current staging
>>> status), I have a compilation error in Yocto while compiling qemu:
>>> In file included from /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/recipe-sysroot/usr/include/xenguest.h:25,
>>> |                  from /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/qemu-5.1.0/hw/i386/xen/xen_platform.c:41:
>>> | /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/recipe-sysroot/usr/include/xenctrl_dom.h:19:10: fatal error: xen/libelf/libelf.h: No such file or directory
>>> |    19 | #include <xen/libelf/libelf.h>
>>> |       |          ^~~~~~~~~~~~~~~~~~~~~
>>> | compilation terminated.
>>> | /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/qemu-5.1.0/rules.mak:69: recipe for target 'hw/i386/xen/xen_platform.o’ failed
>>> 
>>> Xen is using xenctrl_dom.h which need the libelf.h header from xen.
>> Actually this is not coming from your serie and this is actually a problem already present on master.
> 
> ... and fixed on staging.

I can confirm that with tonight staging status this issue is not present anymore.

Regards
Bertrand

Re: Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/

[Bertrand Marquis]

> On 2 Oct 2020, at 10:45, Bertrand Marquis <bertrand.marquis@arm.com> wrote:
> 
> 
> 
>> On 2 Oct 2020, at 05:27, Jürgen Groß <jgross@suse.com> wrote:
>> 
>> On 01.10.20 18:43, Bertrand Marquis wrote:
>>> Hi,
>>>> On 1 Oct 2020, at 17:29, Bertrand Marquis <bertrand.marquis@arm.com> wrote:
>>>> 
>>>> Hi Jan,
>>>> 
>>>>> On 1 Oct 2020, at 17:03, Jan Beulich <jbeulich@suse.com> wrote:
>>>>> 
>>>>> On 10.09.2020 14:09, Jan Beulich wrote:
>>>>>> While looking at what it would take to move around libelf/
>>>>>> in the hypervisor subtree, I've run into this rule, which I
>>>>>> think can do with a few improvements and some simplification.
>>>>>> 
>>>>>> 1: adjust population of acpi/
>>>>>> 2: fix (drop) dependencies of when to populate xen/
>>>>>> 3: adjust population of public headers into xen/
>>>>>> 4: properly install Arm public headers
>>>>>> 5: adjust x86-specific population of xen/
>>>>>> 6: drop remaining -f from ln invocations
>>>>> 
>>>>> May I ask for an ack or otherwise here?
>>>> 
>>>> This is going the right way but with this serie (on top of current staging
>>>> status), I have a compilation error in Yocto while compiling qemu:
>>>> In file included from /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/recipe-sysroot/usr/include/xenguest.h:25,
>>>> |                  from /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/qemu-5.1.0/hw/i386/xen/xen_platform.c:41:
>>>> | /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/recipe-sysroot/usr/include/xenctrl_dom.h:19:10: fatal error: xen/libelf/libelf.h: No such file or directory
>>>> |    19 | #include <xen/libelf/libelf.h>
>>>> |       |          ^~~~~~~~~~~~~~~~~~~~~
>>>> | compilation terminated.
>>>> | /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/qemu-5.1.0/rules.mak:69: recipe for target 'hw/i386/xen/xen_platform.o’ failed
>>>> 
>>>> Xen is using xenctrl_dom.h which need the libelf.h header from xen.
>>> Actually this is not coming from your serie and this is actually a problem already present on master.
>> 
>> ... and fixed on staging.
> 
> I can confirm that with tonight staging status this issue is not present anymore.

… and the serie is building and working properly for arm (including compiling everything
on Yocto).

So:
Tested-by: Bertrand Marquis <bertrand.marquis@arm.com>

And i think it is a good improvement.

Cheers
Bertrand

Re: Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/

[Wei Liu]

On Thu, Oct 01, 2020 at 06:03:09PM +0200, Jan Beulich wrote:
> On 10.09.2020 14:09, Jan Beulich wrote:
> > While looking at what it would take to move around libelf/
> > in the hypervisor subtree, I've run into this rule, which I
> > think can do with a few improvements and some simplification.
> > 
> > 1: adjust population of acpi/
> > 2: fix (drop) dependencies of when to populate xen/
> > 3: adjust population of public headers into xen/
> > 4: properly install Arm public headers
> > 5: adjust x86-specific population of xen/
> > 6: drop remaining -f from ln invocations
> 
> May I ask for an ack or otherwise here?

While I think I agree with Andrew that getting rid of symlink is better,
we're nowhere near that.

This series is an improvement over the status quo, so:

Acked-by: Wei Liu <wl@xen.org>

> 
> Thanks, Jan