[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [Qemu-devel] [PATCH V11 02/15] xen: Make Xen build once.


  • To: Alexander Graf <agraf@xxxxxxx>
  • From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Date: Mon, 28 Mar 2011 15:50:13 +0100
  • Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, QEMU-devel <qemu-devel@xxxxxxxxxx>, Anthony Liguori <anthony@xxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 28 Mar 2011 08:00:43 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=DgbLr1W7YznG6W6dkjWDACNLbt1S3YIf6OiGo53z+aeFVRQS3KZod+IY48KgnTmSF+ Nb6bzS7TBW02K1BfrG62wR4yFsezXUpwNGk4HHbjKMD5mr0QvgLsnpcboCl/nod36Q3Z V+Kirb4gJg8shMTL8Dp52rkMqUu2xQpcScwSE=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On Wed, Mar 23, 2011 at 10:57, Alexander Graf <agraf@xxxxxxx> wrote:
>
> On 01.03.2011, at 19:35, Anthony.Perard@xxxxxxxxxx wrote:
>
>> From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>>
>> xen_domainbuild is now build in libhw. And xen_machine_pv is build only
>> for i386 targets.
>>
>> Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>> ---
>> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.