diff mbox

[1/4] xen: Clean up build system

Message ID 9e6a385a5db82c11b78f87b207fa70136f0c2855.1308637593.git.jan.kiszka@web.de
State New
Headers show

Commit Message

Jan Kiszka June 21, 2011, 6:26 a.m. UTC 
From: Jan Kiszka <jan.kiszka@siemens.com>

Introduce CONFIG_XEN_BACKEND so that this new config solely controls the
target-independent backend build and CONFIG_XEN can focus on per-target
building.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 Makefile.objs   |    4 ++--
 Makefile.target |   13 +++----------
 configure       |    2 +-
 3 files changed, 6 insertions(+), 13 deletions(-)

Comments

Alexander Graf June 21, 2011, 7:21 a.m. UTC | #1 
On 21.06.2011, at 08:26, Jan Kiszka wrote:

> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> Introduce CONFIG_XEN_BACKEND so that this new config solely controls the
> target-independent backend build and CONFIG_XEN can focus on per-target
> building.

What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.


Alex
Jan Kiszka June 21, 2011, 7:23 a.m. UTC | #2 
On 2011-06-21 09:21, Alexander Graf wrote:
> 
> On 21.06.2011, at 08:26, Jan Kiszka wrote:
> 
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> Introduce CONFIG_XEN_BACKEND so that this new config solely controls the
>> target-independent backend build and CONFIG_XEN can focus on per-target
>> building.
> 
> What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.

I doubt that as well. But keeping the backend centrals prevent building
them twice (for i386 and x86_64).

Jan
Alexander Graf June 21, 2011, 7:26 a.m. UTC | #3 
On 21.06.2011, at 09:23, Jan Kiszka wrote:

> On 2011-06-21 09:21, Alexander Graf wrote:
>> 
>> On 21.06.2011, at 08:26, Jan Kiszka wrote:
>> 
>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>> 
>>> Introduce CONFIG_XEN_BACKEND so that this new config solely controls the
>>> target-independent backend build and CONFIG_XEN can focus on per-target
>>> building.
>> 
>> What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.
> 
> I doubt that as well. But keeping the backend centrals prevent building
> them twice (for i386 and x86_64).

How can we not build them twice without risking that target_ulong breaks somewhere along the way?


Alex
Jan Kiszka June 21, 2011, 7:27 a.m. UTC | #4 
On 2011-06-21 09:26, Alexander Graf wrote:
> 
> On 21.06.2011, at 09:23, Jan Kiszka wrote:
> 
>> On 2011-06-21 09:21, Alexander Graf wrote:
>>>
>>> On 21.06.2011, at 08:26, Jan Kiszka wrote:
>>>
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> Introduce CONFIG_XEN_BACKEND so that this new config solely controls the
>>>> target-independent backend build and CONFIG_XEN can focus on per-target
>>>> building.
>>>
>>> What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.
>>
>> I doubt that as well. But keeping the backend centrals prevent building
>> them twice (for i386 and x86_64).
> 
> How can we not build them twice without risking that target_ulong breaks somewhere along the way?

Because the backends don't depend on that. And we already build them
only once, your your logs. :)

Jan
Alexander Graf June 21, 2011, 7:46 a.m. UTC | #5 
On 21.06.2011, at 09:27, Jan Kiszka wrote:

> On 2011-06-21 09:26, Alexander Graf wrote:
>> 
>> On 21.06.2011, at 09:23, Jan Kiszka wrote:
>> 
>>> On 2011-06-21 09:21, Alexander Graf wrote:
>>>> 
>>>> On 21.06.2011, at 08:26, Jan Kiszka wrote:
>>>> 
>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>> 
>>>>> Introduce CONFIG_XEN_BACKEND so that this new config solely controls the
>>>>> target-independent backend build and CONFIG_XEN can focus on per-target
>>>>> building.
>>>> 
>>>> What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.
>>> 
>>> I doubt that as well. But keeping the backend centrals prevent building
>>> them twice (for i386 and x86_64).
>> 
>> How can we not build them twice without risking that target_ulong breaks somewhere along the way?
> 
> Because the backends don't depend on that. And we already build them
> only once, your your logs. :)

So what does the patch change then if it's already only built once?


Alex
Jan Kiszka June 21, 2011, 7:57 a.m. UTC | #6 
On 2011-06-21 09:46, Alexander Graf wrote:
> 
> On 21.06.2011, at 09:27, Jan Kiszka wrote:
> 
>> On 2011-06-21 09:26, Alexander Graf wrote:
>>>
>>> On 21.06.2011, at 09:23, Jan Kiszka wrote:
>>>
>>>> On 2011-06-21 09:21, Alexander Graf wrote:
>>>>>
>>>>> On 21.06.2011, at 08:26, Jan Kiszka wrote:
>>>>>
>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>
>>>>>> Introduce CONFIG_XEN_BACKEND so that this new config solely controls the
>>>>>> target-independent backend build and CONFIG_XEN can focus on per-target
>>>>>> building.
>>>>>
>>>>> What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.
>>>>
>>>> I doubt that as well. But keeping the backend centrals prevent building
>>>> them twice (for i386 and x86_64).
>>>
>>> How can we not build them twice without risking that target_ulong breaks somewhere along the way?
>>
>> Because the backends don't depend on that. And we already build them
>> only once, your your logs. :)
> 
> So what does the patch change then if it's already only built once?

It allows to clean up Makefile.target like I did as CONFIG_XEN is no
longer defined for all targets but only for those that actually support Xen.

Jan
Alexander Graf June 21, 2011, 8:15 a.m. UTC | #7 
On 21.06.2011, at 09:57, Jan Kiszka wrote:

> On 2011-06-21 09:46, Alexander Graf wrote:
>> 
>> On 21.06.2011, at 09:27, Jan Kiszka wrote:
>> 
>>> On 2011-06-21 09:26, Alexander Graf wrote:
>>>> 
>>>> On 21.06.2011, at 09:23, Jan Kiszka wrote:
>>>> 
>>>>> On 2011-06-21 09:21, Alexander Graf wrote:
>>>>>> 
>>>>>> On 21.06.2011, at 08:26, Jan Kiszka wrote:
>>>>>> 
>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>> 
>>>>>>> Introduce CONFIG_XEN_BACKEND so that this new config solely controls the
>>>>>>> target-independent backend build and CONFIG_XEN can focus on per-target
>>>>>>> building.
>>>>>> 
>>>>>> What's the incentive here? I very much doubt we'll ever want to support xen on !x86. In fact, the better solution would probably be to just move every build component to x86 specific code.
>>>>> 
>>>>> I doubt that as well. But keeping the backend centrals prevent building
>>>>> them twice (for i386 and x86_64).
>>>> 
>>>> How can we not build them twice without risking that target_ulong breaks somewhere along the way?
>>> 
>>> Because the backends don't depend on that. And we already build them
>>> only once, your your logs. :)
>> 
>> So what does the patch change then if it's already only built once?
> 
> It allows to clean up Makefile.target like I did as CONFIG_XEN is no
> longer defined for all targets but only for those that actually support Xen.

Seems to make sense. Let's hope it doesn't break anything :)


Alex
Ian Jackson June 21, 2011, 1:01 p.m. UTC | #8 
Alexander Graf writes ("[Xen-devel] Re: [PATCH 1/4] xen: Clean up build system"):
> On 21.06.2011, at 08:26, Jan Kiszka wrote:
> > From: Jan Kiszka <jan.kiszka@siemens.com>
> > 
> > Introduce CONFIG_XEN_BACKEND so that this new config solely controls the
> > target-independent backend build and CONFIG_XEN can focus on per-target
> > building.
> 
> What's the incentive here? I very much doubt we'll ever want to
> support xen on !x86. In fact, the better solution would probably be
> to just move every build component to x86 specific code.

In the past Xen has supported ppc too and there is a half-congealed
arm port.  It's not a good assumption that Xen is x86-specific.

Ian.
Jan Kiszka June 21, 2011, 1:16 p.m. UTC | #9 
On 2011-06-21 15:01, Ian Jackson wrote:
> Alexander Graf writes ("[Xen-devel] Re: [PATCH 1/4] xen: Clean up build system"):
>> On 21.06.2011, at 08:26, Jan Kiszka wrote:
>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> Introduce CONFIG_XEN_BACKEND so that this new config solely controls the
>>> target-independent backend build and CONFIG_XEN can focus on per-target
>>> building.
>>
>> What's the incentive here? I very much doubt we'll ever want to
>> support xen on !x86. In fact, the better solution would probably be
>> to just move every build component to x86 specific code.
> 
> In the past Xen has supported ppc too and there is a half-congealed
> arm port.  It's not a good assumption that Xen is x86-specific.

We aren't setting x86 dependency into stone here, we are just trying to
keep support for what is there today clean and simple. The build system
can become more advanced again once there is support for modern ARM or
PowerPC. But until other Xen archs materialize into a usable form, it's
futile to design for their past or possible future requirements. KVM is
also no longer considering IA64 when cleaning up.

Jan
Alexander Graf June 21, 2011, 1:18 p.m. UTC | #10 
On 21.06.2011, at 15:01, Ian Jackson wrote:

> Alexander Graf writes ("[Xen-devel] Re: [PATCH 1/4] xen: Clean up build system"):
>> On 21.06.2011, at 08:26, Jan Kiszka wrote:
>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>> 
>>> Introduce CONFIG_XEN_BACKEND so that this new config solely controls the
>>> target-independent backend build and CONFIG_XEN can focus on per-target
>>> building.
>> 
>> What's the incentive here? I very much doubt we'll ever want to
>> support xen on !x86. In fact, the better solution would probably be
>> to just move every build component to x86 specific code.
> 
> In the past Xen has supported ppc too and there is a half-congealed
> arm port.  It's not a good assumption that Xen is x86-specific.

Well, is there a realistic chance that we'll ever get non-x86 Xen code into upstream Qemu? I don't know how well the arm port's been doing, but the PPC one is long dead and was always just a toy. I'm fairly sure nobody really cares about the IA64 port either these days.


Alex
Stefano Stabellini June 21, 2011, 1:48 p.m. UTC | #11 
On Tue, 21 Jun 2011, Alexander Graf wrote:
> On 21.06.2011, at 15:01, Ian Jackson wrote:
> 
> > Alexander Graf writes ("[Xen-devel] Re: [PATCH 1/4] xen: Clean up build system"):
> >> On 21.06.2011, at 08:26, Jan Kiszka wrote:
> >>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>> 
> >>> Introduce CONFIG_XEN_BACKEND so that this new config solely controls the
> >>> target-independent backend build and CONFIG_XEN can focus on per-target
> >>> building.
> >> 
> >> What's the incentive here? I very much doubt we'll ever want to
> >> support xen on !x86. In fact, the better solution would probably be
> >> to just move every build component to x86 specific code.
> > 
> > In the past Xen has supported ppc too and there is a half-congealed
> > arm port.  It's not a good assumption that Xen is x86-specific.
> 
> Well, is there a realistic chance that we'll ever get non-x86 Xen code into upstream Qemu? I don't know how well the arm port's been doing, but the PPC one is long dead and was always just a toy. I'm fairly sure nobody really cares about the IA64 port either these days.

There is a realistic chance we'll get ARM Xen code into upstream Qemu.
That said, I don't think this patch would prevent it from happening.
Also I tested it and it works OK, so it is fine by me.
diff mbox

Patch

diff --git a/Makefile.objs b/Makefile.objs
index cea15e4..1635df6 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -155,8 +155,8 @@  slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o
 common-obj-$(CONFIG_SLIRP) += $(addprefix slirp/, $(slirp-obj-y))
 
 # xen backend driver support
-common-obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o
-common-obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o
+common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
+common-obj-$(CONFIG_XEN_BACKEND) += xen_console.o xenfb.o xen_disk.o xen_nic.o
 
 ######################################################################
 # libuser
diff --git a/Makefile.target b/Makefile.target
index b1a0f6d..f325554 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -3,6 +3,8 @@ 
 GENERATED_HEADERS = config-target.h
 CONFIG_NO_PCI = $(if $(subst n,,$(CONFIG_PCI)),n,y)
 CONFIG_NO_KVM = $(if $(subst n,,$(CONFIG_KVM)),n,y)
+CONFIG_NO_XEN = $(if $(subst n,,$(CONFIG_XEN)),n,y)
+CONFIG_NO_XEN_MAPCACHE = $(if $(subst n,,$(CONFIG_XEN_MAPCACHE)),n,y)
 
 include ../config-host.mak
 include config-devices.mak
@@ -203,17 +205,8 @@  QEMU_CFLAGS += $(VNC_SASL_CFLAGS)
 QEMU_CFLAGS += $(VNC_JPEG_CFLAGS)
 QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
 
-# xen backend driver support
-obj-i386-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o
-
-ifeq ($(TARGET_BASE_ARCH), i386)
-  CONFIG_NO_XEN = $(if $(subst n,,$(CONFIG_XEN)),n,y)
-else
-  CONFIG_NO_XEN = y
-endif
 # xen support
-CONFIG_NO_XEN_MAPCACHE = $(if $(subst n,,$(CONFIG_XEN_MAPCACHE)),n,y)
-obj-i386-$(CONFIG_XEN) += xen-all.o
+obj-$(CONFIG_XEN) += xen-all.o xen_machine_pv.o xen_domainbuild.o
 obj-$(CONFIG_NO_XEN) += xen-stub.o
 obj-i386-$(CONFIG_XEN_MAPCACHE) += xen-mapcache.o
 obj-$(CONFIG_NO_XEN_MAPCACHE) += xen-mapcache-stub.o
diff --git a/configure b/configure
index 44c092a..7991489 100755
--- a/configure
+++ b/configure
@@ -2944,7 +2944,7 @@  if test "$bluez" = "yes" ; then
   echo "BLUEZ_CFLAGS=$bluez_cflags" >> $config_host_mak
 fi
 if test "$xen" = "yes" ; then
-  echo "CONFIG_XEN=y" >> $config_host_mak
+  echo "CONFIG_XEN_BACKEND=y" >> $config_host_mak
   echo "CONFIG_XEN_CTRL_INTERFACE_VERSION=$xen_ctrl_version" >> $config_host_mak
 fi
 if test "$io_thread" = "yes" ; then