Re: [Xen-devel] Re: [Qemu-devel] [PATCH V11 02/15] xen: Make Xen build once.
On Wed, Mar 23, 2011 at 10:57, Alexander Graf ag...@suse.de wrote: On 01.03.2011, at 19:35, anthony.per...@citrix.com wrote: From: Anthony PERARD anthony.per...@citrix.com xen_domainbuild is now build in libhw. And xen_machine_pv is build only for i386 targets. Signed-off-by: Anthony PERARD anthony.per...@citrix.com --- Makefile.objs | 3 +++ Makefile.target | 2 +- hw/xen_domainbuild.c | 10 +- hw/xen_domainbuild.h | 5 +++-- hw/xen_machine_pv.c | 2 +- 5 files changed, 13 insertions(+), 9 deletions(-) diff --git a/Makefile.objs b/Makefile.objs index 9e98a66..8034115 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -269,6 +269,9 @@ hw-obj-$(CONFIG_DP8393X) += dp8393x.o hw-obj-$(CONFIG_DS1225Y) += ds1225y.o hw-obj-$(CONFIG_MIPSNET) += mipsnet.o +# Xen +hw-obj-$(CONFIG_XEN) += xen_domainbuild.o Why is this in generic code? Xen is x86 only and really should stay that way IMHO. I just try to build more object globally to avoid unnecessary i386-isms. + # Sound sound-obj-y = sound-obj-$(CONFIG_SB16) += sb16.o diff --git a/Makefile.target b/Makefile.target index 220589e..ab0a570 100644 --- a/Makefile.target +++ b/Makefile.target @@ -206,7 +206,7 @@ QEMU_CFLAGS += $(VNC_JPEG_CFLAGS) QEMU_CFLAGS += $(VNC_PNG_CFLAGS) # xen backend driver support -obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o +obj-i386-$(CONFIG_XEN) += xen_machine_pv.o # Inter-VM PCI shared memory obj-$(CONFIG_KVM) += ivshmem.o diff --git a/hw/xen_domainbuild.c b/hw/xen_domainbuild.c index 7f1fd66..b73d47f 100644 --- a/hw/xen_domainbuild.c +++ b/hw/xen_domainbuild.c @@ -1,9 +1,9 @@ #include signal.h -#include xen_backend.h -#include xen_domainbuild.h #include sysemu.h #include qemu-timer.h #include qemu-log.h +#include xen_backend.h +#include xen_domainbuild.h #include xenguest.h @@ -49,7 +49,7 @@ static int xenstore_domain_mkdir(char *path) } int xenstore_domain_init1(const char *kernel, const char *ramdisk, - const char *cmdline) + const char *cmdline, ram_addr_t ram_size) Isn't ram_size a global anyways? What's the rationale behind moving it to a parameter? Not saying I'm against it, just missed the reasoning here :) I put ram_size in a parameter because I don't found a way to access to is global variable, and also because in these function, ram_size is read only. So, I can just remove this patch and just put both xen_machine_pv xen_domainbuild in obj-i386-y. Regards, -- Anthony PERARD
Re: [Xen-devel] Re: [Qemu-devel] [PATCH V11 02/15] xen: Make Xen build once.
On 03/28/2011 04:50 PM, Anthony PERARD wrote: On Wed, Mar 23, 2011 at 10:57, Alexander Grafag...@suse.de wrote: On 01.03.2011, at 19:35, anthony.per...@citrix.com wrote: From: Anthony PERARDanthony.per...@citrix.com xen_domainbuild is now build in libhw. And xen_machine_pv is build only for i386 targets. Signed-off-by: Anthony PERARDanthony.per...@citrix.com --- Makefile.objs|3 +++ Makefile.target |2 +- hw/xen_domainbuild.c | 10 +- hw/xen_domainbuild.h |5 +++-- hw/xen_machine_pv.c |2 +- 5 files changed, 13 insertions(+), 9 deletions(-) diff --git a/Makefile.objs b/Makefile.objs index 9e98a66..8034115 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -269,6 +269,9 @@ hw-obj-$(CONFIG_DP8393X) += dp8393x.o hw-obj-$(CONFIG_DS1225Y) += ds1225y.o hw-obj-$(CONFIG_MIPSNET) += mipsnet.o +# Xen +hw-obj-$(CONFIG_XEN) += xen_domainbuild.o Why is this in generic code? Xen is x86 only and really should stay that way IMHO. I just try to build more object globally to avoid unnecessary i386-isms. + # Sound sound-obj-y = sound-obj-$(CONFIG_SB16) += sb16.o diff --git a/Makefile.target b/Makefile.target index 220589e..ab0a570 100644 --- a/Makefile.target +++ b/Makefile.target @@ -206,7 +206,7 @@ QEMU_CFLAGS += $(VNC_JPEG_CFLAGS) QEMU_CFLAGS += $(VNC_PNG_CFLAGS) # xen backend driver support -obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o +obj-i386-$(CONFIG_XEN) += xen_machine_pv.o # Inter-VM PCI shared memory obj-$(CONFIG_KVM) += ivshmem.o diff --git a/hw/xen_domainbuild.c b/hw/xen_domainbuild.c index 7f1fd66..b73d47f 100644 --- a/hw/xen_domainbuild.c +++ b/hw/xen_domainbuild.c @@ -1,9 +1,9 @@ #includesignal.h -#include xen_backend.h -#include xen_domainbuild.h #include sysemu.h #include qemu-timer.h #include qemu-log.h +#include xen_backend.h +#include xen_domainbuild.h #includexenguest.h @@ -49,7 +49,7 @@ static int xenstore_domain_mkdir(char *path) } int xenstore_domain_init1(const char *kernel, const char *ramdisk, - const char *cmdline) + const char *cmdline, ram_addr_t ram_size) Isn't ram_size a global anyways? What's the rationale behind moving it to a parameter? Not saying I'm against it, just missed the reasoning here :) I put ram_size in a parameter because I don't found a way to access to is global variable, and also because in these function, ram_size is read only. So, I can just remove this patch and just put both xen_machine_pv xen_domainbuild in obj-i386-y. Sounds good to me. No need to build stuff generically that won't be used generically :). Alex
