# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327325262 -3600
# Node ID 88bddf1f0bafade6431651c5257bd02780596579
# Parent 80fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd
pv drivers: wrap xen_cpuid_base()
Allow compilation of PVonHVM drivers with forward-ported xenlinux
sources in openSuSE 12.1. xen_cpuid_base() is now in mainline, the copy
in the xen tree leads to a compilation error.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
diff -r 80fdf2182bc6 -r 88bddf1f0baf
unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
@@ -118,6 +118,7 @@ unsigned long alloc_xen_mmio(unsigned lo
#ifndef __ia64__
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)
static uint32_t xen_cpuid_base(void)
{
uint32_t base, eax, ebx, ecx, edx;
@@ -136,6 +137,7 @@ static uint32_t xen_cpuid_base(void)
return 0;
}
+#endif
static int init_hypercall_stubs(void)
{
>>> On 23.01.12 at 14:49, Olaf Hering <olaf@aepfle.de> wrote: > # HG changeset patch > # User Olaf Hering <olaf@aepfle.de> > # Date 1327325262 -3600 > # Node ID 88bddf1f0bafade6431651c5257bd02780596579 > # Parent 80fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd > pv drivers: wrap xen_cpuid_base() > > Allow compilation of PVonHVM drivers with forward-ported xenlinux > sources in openSuSE 12.1. xen_cpuid_base() is now in mainline, the copy > in the xen tree leads to a compilation error. > > Signed-off-by: Olaf Hering <olaf@aepfle.de> > > diff -r 80fdf2182bc6 -r 88bddf1f0baf > unmodified_drivers/linux-2.6/platform-pci/platform-pci.c > --- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c > +++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c > @@ -118,6 +118,7 @@ unsigned long alloc_xen_mmio(unsigned lo > > #ifndef __ia64__ > > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)Given that the PV drivers must be building fine for SLE11 SP2, which is 3.0-based, I wonder if this really is the correct fix (and doesn''t rather break the build). The first thing coming to mind is that arch/x86/include/asm/xen/hypervisor.h shouldn''t get included here (and hence there shouldn''t be any conflict). Are you perhaps trying to build the PV drivers against a pv-ops-enabled configuration (which is a wrong to try afaict)? Jan> static uint32_t xen_cpuid_base(void) > { > uint32_t base, eax, ebx, ecx, edx; > @@ -136,6 +137,7 @@ static uint32_t xen_cpuid_base(void) > > return 0; > } > +#endif > > static int init_hypercall_stubs(void) > { > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel
On Mon, Jan 23, Jan Beulich wrote:> > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38) > > Given that the PV drivers must be building fine for SLE11 SP2, which > is 3.0-based, I wonder if this really is the correct fix (and doesn''t > rather break the build). The first thing coming to mind is that > arch/x86/include/asm/xen/hypervisor.h shouldn''t get included here > (and hence there shouldn''t be any conflict). Are you perhaps trying > to build the PV drivers against a pv-ops-enabled configuration (which > is a wrong to try afaict)?Its an ordinary kernel-source tree. git describe d9b8ca8474fd4fdd43ba6d97a4fee8b49b978067 v2.6.37-rc5-2-gd9b8ca8 The function appears in 2.6.38, so I think the version number is correct. Olaf
>>> On 23.01.12 at 15:22, Olaf Hering <olaf@aepfle.de> wrote: > On Mon, Jan 23, Jan Beulich wrote: > >> > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38) >> >> Given that the PV drivers must be building fine for SLE11 SP2, which >> is 3.0-based, I wonder if this really is the correct fix (and doesn''t >> rather break the build). The first thing coming to mind is that >> arch/x86/include/asm/xen/hypervisor.h shouldn''t get included here >> (and hence there shouldn''t be any conflict). Are you perhaps trying >> to build the PV drivers against a pv-ops-enabled configuration (which >> is a wrong to try afaict)? > > Its an ordinary kernel-source tree.That''s not the question - it matters what your .config is set to.> git describe d9b8ca8474fd4fdd43ba6d97a4fee8b49b978067 > v2.6.37-rc5-2-gd9b8ca8How is 2.6.37-rc5 related to this?> The function appears in 2.6.38, so I think the version number is correct.The version number appears to be correct (in 2.6.36 and 2.6.37 the function existed, but was static in arch/x86/xen/enlighten.c), but again that wasn''t my point. Instead you will want to point out how you ended up including the declaring header. (I''m running the PV driver build every once in a while, and I know it had worked fine for SLE11 SP2 sources a while back. Let me see how things look right now: master (3.2): getting an unrelated error apparently due to a missing header inclusion, platform-pci/platform-pci.c building fine sle11sp2 (3.0): building fine.) Jan
On Mon, Jan 23, Jan Beulich wrote:> sle11sp2 (3.0): building fine.)Not for the xen.src.rpm, it also contains this change. I think the reason is that the kernel sources are searched before the xen sources for asm/hypervisor.h: /usr/src/linux-3.0.13-0.11/arch/x86/include/asm/hypervisor.h /usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/include/asm/hypervisor.h This is the cmdline as shown by make -C /usr/src/linux-obj/x86_64/default modules M=/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default V=1 abuild@bax:/usr/src/linux-obj/x86_64/default> gcc -Wp,-MD,/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/.platform-pci.o.d -nostdinc -isystem /usr/lib64/gcc/x86_64-suse-linux/4.3/include -I/usr/src/linux-3.0.13-0.11/arch/x86/include -Iarch/x86/include/generated -Iinclude -I/usr/src/linux-3.0.13-0.11/include -include include/generated/autoconf.h -I/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 -mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -pipe -Wno-sign-compare -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -fno-stack-protector -fomit-frame-pointer -fasynchronous-unwind-tables -g -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -D__XEN_INTERFACE_VERSION__=0x00030205 -DCONFIG_XEN_COMPAT=0xffffff -I/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/include -I/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/compat-include -DHAVE_XEN_PLATFORM_COMPAT_H -include /usr/src/linux-3.0.13-0.11-obj/x86_64/default/include/generated/autoconf.h -I/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(platform_pci)" -D"KBUILD_MODNAME=KBUILD_STR(xen_platform_pci)" -c -o /usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/.tmp_platform-pci.o /usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/platform-pci.c --save-temps gcc: warning: -pipe ignored because -save-temps specified /usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/platform-pci.c:121: error: redefinition of ''xen_cpuid_base'' /usr/src/linux-3.0.13-0.11/arch/x86/include/asm/xen/hypervisor.h:43: error: previous definition of ''xen_cpuid_base'' was here Its probably not a bug to prefer kernel-source over local directories. Olaf
>>> On 24.01.12 at 11:27, Olaf Hering <olaf@aepfle.de> wrote: > On Mon, Jan 23, Jan Beulich wrote: > >> sle11sp2 (3.0): building fine.) > > Not for the xen.src.rpm, it also contains this change. I think theOh, I wasn''t even aware of that custom change of ours.> reason is that the kernel sources are searched before the xen sources > for asm/hypervisor.h: > > /usr/src/linux-3.0.13-0.11/arch/x86/include/asm/hypervisor.h > /usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/include/asm/hypervisor.h >... > Its probably not a bug to prefer kernel-source over local directories.Agreed. While it''s still a hack (what if the function got un-inlined and exported), Acked-by: Jan Beulich <jbeulich@suse.com>