* [PATCH 1/6] tools/include: adjust population of acpi/
2020-09-10 12:09 [PATCH 0/6] tools/include: adjustments to the population of xen/ Jan Beulich
@ 2020-09-10 12:11 ` Jan Beulich
2020-09-10 12:12 ` [PATCH 2/6] tools/include: fix (drop) dependencies of when to populate xen/ Jan Beulich
` (7 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Jan Beulich @ 2020-09-10 12:11 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org; +Cc: Ian Jackson, Wei Liu
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 2/6] tools/include: fix (drop) dependencies of when to populate xen/
2020-09-10 12:09 [PATCH 0/6] tools/include: adjustments to the population of xen/ Jan Beulich
2020-09-10 12:11 ` [PATCH 1/6] tools/include: adjust population of acpi/ Jan Beulich
@ 2020-09-10 12:12 ` Jan Beulich
2020-09-10 12:12 ` [PATCH 3/6] tools/include: adjust population of public headers into xen/ Jan Beulich
` (6 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Jan Beulich @ 2020-09-10 12:12 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org; +Cc: Ian Jackson, Wei Liu
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 3/6] tools/include: adjust population of public headers into xen/
2020-09-10 12:09 [PATCH 0/6] tools/include: adjustments to the population of xen/ Jan Beulich
2020-09-10 12:11 ` [PATCH 1/6] tools/include: adjust population of acpi/ Jan Beulich
2020-09-10 12:12 ` [PATCH 2/6] tools/include: fix (drop) dependencies of when to populate xen/ Jan Beulich
@ 2020-09-10 12:12 ` Jan Beulich
2020-09-10 12:12 ` [PATCH 4/6] tools/include: properly install Arm public headers Jan Beulich
` (5 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Jan Beulich @ 2020-09-10 12:12 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org; +Cc: Ian Jackson, Wei Liu
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 4/6] tools/include: properly install Arm public headers
2020-09-10 12:09 [PATCH 0/6] tools/include: adjustments to the population of xen/ Jan Beulich
` (2 preceding siblings ...)
2020-09-10 12:12 ` [PATCH 3/6] tools/include: adjust population of public headers into xen/ Jan Beulich
@ 2020-09-10 12:12 ` Jan Beulich
2020-09-10 12:13 ` [PATCH 5/6] tools/include: adjust x86-specific population of xen/ Jan Beulich
` (4 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Jan Beulich @ 2020-09-10 12:12 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org; +Cc: Ian Jackson, Wei Liu
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 5/6] tools/include: adjust x86-specific population of xen/
2020-09-10 12:09 [PATCH 0/6] tools/include: adjustments to the population of xen/ Jan Beulich
` (3 preceding siblings ...)
2020-09-10 12:12 ` [PATCH 4/6] tools/include: properly install Arm public headers Jan Beulich
@ 2020-09-10 12:13 ` Jan Beulich
2020-09-10 12:13 ` [PATCH 6/6] tools/include: drop remaining -f from ln invocations Jan Beulich
` (3 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Jan Beulich @ 2020-09-10 12:13 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org; +Cc: Ian Jackson, Wei Liu
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 6/6] tools/include: drop remaining -f from ln invocations
2020-09-10 12:09 [PATCH 0/6] tools/include: adjustments to the population of xen/ Jan Beulich
` (4 preceding siblings ...)
2020-09-10 12:13 ` [PATCH 5/6] tools/include: adjust x86-specific population of xen/ Jan Beulich
@ 2020-09-10 12:13 ` Jan Beulich
2020-09-10 13:51 ` [PATCH 0/6] tools/include: adjustments to the population of xen/ Andrew Cooper
` (2 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Jan Beulich @ 2020-09-10 12:13 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org; +Cc: Ian Jackson, Wei Liu
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/
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 0/6] tools/include: adjustments to the population of xen/
2020-09-10 12:09 [PATCH 0/6] tools/include: adjustments to the population of xen/ Jan Beulich
` (5 preceding siblings ...)
2020-09-10 12:13 ` [PATCH 6/6] tools/include: drop remaining -f from ln invocations Jan Beulich
@ 2020-09-10 13:51 ` Andrew Cooper
2020-09-10 14:00 ` Jürgen Groß
2020-09-10 14:06 ` Jan Beulich
2020-09-28 8:30 ` Ping: " Jan Beulich
2020-10-01 16:03 ` Jan Beulich
8 siblings, 2 replies; 18+ messages in thread
From: Andrew Cooper @ 2020-09-10 13:51 UTC (permalink / raw)
To: Jan Beulich, xen-devel@lists.xenproject.org; +Cc: Ian Jackson, Wei Liu
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 0/6] tools/include: adjustments to the population of xen/
2020-09-10 13:51 ` [PATCH 0/6] tools/include: adjustments to the population of xen/ Andrew Cooper
@ 2020-09-10 14:00 ` Jürgen Groß
2020-09-10 14:06 ` Jan Beulich
1 sibling, 0 replies; 18+ messages in thread
From: Jürgen Groß @ 2020-09-10 14:00 UTC (permalink / raw)
To: Andrew Cooper, Jan Beulich, xen-devel@lists.xenproject.org
Cc: Ian Jackson, Wei Liu
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/6] tools/include: adjustments to the population of xen/
2020-09-10 13:51 ` [PATCH 0/6] tools/include: adjustments to the population of xen/ Andrew Cooper
2020-09-10 14:00 ` Jürgen Groß
@ 2020-09-10 14:06 ` Jan Beulich
1 sibling, 0 replies; 18+ messages in thread
From: Jan Beulich @ 2020-09-10 14:06 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel@lists.xenproject.org, Ian Jackson, Wei Liu
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/
2020-09-10 12:09 [PATCH 0/6] tools/include: adjustments to the population of xen/ Jan Beulich
` (6 preceding siblings ...)
2020-09-10 13:51 ` [PATCH 0/6] tools/include: adjustments to the population of xen/ Andrew Cooper
@ 2020-09-28 8:30 ` Jan Beulich
2020-10-01 16:03 ` Jan Beulich
8 siblings, 0 replies; 18+ messages in thread
From: Jan Beulich @ 2020-09-28 8:30 UTC (permalink / raw)
To: Ian Jackson, Wei Liu; +Cc: xen-devel@lists.xenproject.org
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/
2020-09-10 12:09 [PATCH 0/6] tools/include: adjustments to the population of xen/ Jan Beulich
` (7 preceding siblings ...)
2020-09-28 8:30 ` Ping: " Jan Beulich
@ 2020-10-01 16:03 ` Jan Beulich
2020-10-01 16:29 ` Bertrand Marquis
2020-10-02 11:52 ` Wei Liu
8 siblings, 2 replies; 18+ messages in thread
From: Jan Beulich @ 2020-10-01 16:03 UTC (permalink / raw)
To: Ian Jackson, Wei Liu; +Cc: xen-devel@lists.xenproject.org
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/
2020-10-01 16:03 ` Jan Beulich
@ 2020-10-01 16:29 ` Bertrand Marquis
2020-10-01 16:43 ` Bertrand Marquis
2020-10-02 11:52 ` Wei Liu
1 sibling, 1 reply; 18+ messages in thread
From: Bertrand Marquis @ 2020-10-01 16:29 UTC (permalink / raw)
To: Jan Beulich; +Cc: Ian Jackson, Wei Liu, xen-devel@lists.xenproject.org
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/
2020-10-01 16:29 ` Bertrand Marquis
@ 2020-10-01 16:43 ` Bertrand Marquis
2020-10-02 4:27 ` Jürgen Groß
0 siblings, 1 reply; 18+ messages in thread
From: Bertrand Marquis @ 2020-10-01 16:43 UTC (permalink / raw)
To: Jan Beulich; +Cc: Ian Jackson, Wei Liu, xen-devel@lists.xenproject.org
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/
2020-10-01 16:43 ` Bertrand Marquis
@ 2020-10-02 4:27 ` Jürgen Groß
2020-10-02 9:46 ` Bertrand Marquis
0 siblings, 1 reply; 18+ messages in thread
From: Jürgen Groß @ 2020-10-02 4:27 UTC (permalink / raw)
To: Bertrand Marquis, Jan Beulich
Cc: Ian Jackson, Wei Liu, xen-devel@lists.xenproject.org
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/
2020-10-02 4:27 ` Jürgen Groß
@ 2020-10-02 9:46 ` Bertrand Marquis
2020-10-02 10:17 ` Bertrand Marquis
0 siblings, 1 reply; 18+ messages in thread
From: Bertrand Marquis @ 2020-10-02 9:46 UTC (permalink / raw)
To: Jürgen Groß
Cc: Jan Beulich, Ian Jackson, Wei Liu, xen-devel@lists.xenproject.org
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/
2020-10-02 9:46 ` Bertrand Marquis
@ 2020-10-02 10:17 ` Bertrand Marquis
0 siblings, 0 replies; 18+ messages in thread
From: Bertrand Marquis @ 2020-10-02 10:17 UTC (permalink / raw)
To: Jürgen Groß
Cc: Jan Beulich, Ian Jackson, Wei Liu, xen-devel@lists.xenproject.org
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Ping: [PATCH 0/6] tools/include: adjustments to the population of xen/
2020-10-01 16:03 ` Jan Beulich
2020-10-01 16:29 ` Bertrand Marquis
@ 2020-10-02 11:52 ` Wei Liu
1 sibling, 0 replies; 18+ messages in thread
From: Wei Liu @ 2020-10-02 11:52 UTC (permalink / raw)
To: Jan Beulich; +Cc: Ian Jackson, Wei Liu, xen-devel@lists.xenproject.org
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
^ permalink raw reply [flat|nested] 18+ messages in thread