| Message ID | 2a9f86aa-9104-8a45-cd21-72acd693f924@suse.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | tools/include: adjustments to the population of xen/ | expand |
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
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
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
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
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
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
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
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
> 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
> 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
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