WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Alexander Graf <agraf@xxxxxxx>
Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH V11 02/15] xen: Make Xen build once.
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
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=p9YnRWF0JsrXiBd2GHPWNcpzts9HuV5ixsxwrhSsyBs=; b=wtb1H7NRiEuaMvM7YHGSjl9TxXKgyoci20biiDCGptwwpGPOvrOBAz5f8otKsK8IFR L4PMpVBd1OPmwbuMKa5uVTY3Eof6nio0UfIDM/GKTrUX4WbMplsSdSpZpD+BadzfZpBQ /qulPe/K4hvOmDKfCBTrTy6FejZ/PeZqIdhSY=
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <315066AB-DAF8-4665-A987-CBB0DD553F47@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1299004529-31290-1-git-send-email-anthony.perard@xxxxxxxxxx> <1299004529-31290-3-git-send-email-anthony.perard@xxxxxxxxxx> <315066AB-DAF8-4665-A987-CBB0DD553F47@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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