Message ID | 9e6a385a5db82c11b78f87b207fa70136f0c2855.1308637593.git.jan.kiszka@web.de |
---|---|
State | New |
Headers | show |
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
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
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
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
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
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
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
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.
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
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
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 --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