| Message ID | 1295032341-6926-3-git-send-email-daahern@cisco.com |
|---|---|
| State | New |
| Headers | show |
On Fri, Jan 14, 2011 at 7:12 PM, David Ahern <daahern@cisco.com> wrote: > Currently, device config settings in the default-configs file are not propogated into the config*.h files. While the Makefile rules observe them through the *.mak files, the CONFIG options are not usable within the .c files. > > This patch adds the settings to the header files. To do that the host devices make file is renamed to config-host-devices.mak and the target devices mak file to config-target-devices.mak. NACK, see this thread for the previous discussion: http://lists.nongnu.org/archive/html/qemu-devel/2010-05/msg02268.html
On 01/14/11 13:17, Blue Swirl wrote: > On Fri, Jan 14, 2011 at 7:12 PM, David Ahern <daahern@cisco.com> wrote: >> Currently, device config settings in the default-configs file are not propogated into the config*.h files. While the Makefile rules observe them through the *.mak files, the CONFIG options are not usable within the .c files. >> >> This patch adds the settings to the header files. To do that the host devices make file is renamed to config-host-devices.mak and the target devices mak file to config-target-devices.mak. > > NACK, see this thread for the previous discussion: > http://lists.nongnu.org/archive/html/qemu-devel/2010-05/msg02268.html hmm.... so there is no interest in making the existing design actually work? It's reinvent the config design or nothing? I'm looking to compile out all device models not relevant to my use case. David
On Fri, Jan 14, 2011 at 8:24 PM, David Ahern <daahern@cisco.com> wrote: > > > On 01/14/11 13:17, Blue Swirl wrote: >> On Fri, Jan 14, 2011 at 7:12 PM, David Ahern <daahern@cisco.com> wrote: >>> Currently, device config settings in the default-configs file are not propogated into the config*.h files. While the Makefile rules observe them through the *.mak files, the CONFIG options are not usable within the .c files. >>> >>> This patch adds the settings to the header files. To do that the host devices make file is renamed to config-host-devices.mak and the target devices mak file to config-target-devices.mak. >> >> NACK, see this thread for the previous discussion: >> http://lists.nongnu.org/archive/html/qemu-devel/2010-05/msg02268.html > > hmm.... so there is no interest in making the existing design actually > work? It's reinvent the config design or nothing? > > I'm looking to compile out all device models not relevant to my use case. That's OK, but the correct fix is to change the design of the machine model to something more advanced where the unwanted objects are simply not linked in, without any changes to board code. This is not so trivial and also many devices are not architecturally clean yet.
On 01/14/11 13:31, Blue Swirl wrote: > On Fri, Jan 14, 2011 at 8:24 PM, David Ahern <daahern@cisco.com> wrote: >> >> >> On 01/14/11 13:17, Blue Swirl wrote: >>> On Fri, Jan 14, 2011 at 7:12 PM, David Ahern <daahern@cisco.com> wrote: >>>> Currently, device config settings in the default-configs file are not propogated into the config*.h files. While the Makefile rules observe them through the *.mak files, the CONFIG options are not usable within the .c files. >>>> >>>> This patch adds the settings to the header files. To do that the host devices make file is renamed to config-host-devices.mak and the target devices mak file to config-target-devices.mak. >>> >>> NACK, see this thread for the previous discussion: >>> http://lists.nongnu.org/archive/html/qemu-devel/2010-05/msg02268.html >> >> hmm.... so there is no interest in making the existing design actually >> work? It's reinvent the config design or nothing? >> >> I'm looking to compile out all device models not relevant to my use case. > > That's OK, but the correct fix is to change the design of the machine > model to something more advanced where the unwanted objects are simply > not linked in, without any changes to board code. This is not so > trivial and also many devices are not architecturally clean yet. A lot of changes are need to obtain that goal, and I am not the right person to do them. Until that ideal design can be developed and implemented why not take a small patch that fixes the existing design? It's not a major change -- a very small one actually (4 files, 13 lines modified). David
On Fri, Jan 14, 2011 at 8:47 PM, David Ahern <daahern@cisco.com> wrote: > > > On 01/14/11 13:31, Blue Swirl wrote: >> On Fri, Jan 14, 2011 at 8:24 PM, David Ahern <daahern@cisco.com> wrote: >>> >>> >>> On 01/14/11 13:17, Blue Swirl wrote: >>>> On Fri, Jan 14, 2011 at 7:12 PM, David Ahern <daahern@cisco.com> wrote: >>>>> Currently, device config settings in the default-configs file are not propogated into the config*.h files. While the Makefile rules observe them through the *.mak files, the CONFIG options are not usable within the .c files. >>>>> >>>>> This patch adds the settings to the header files. To do that the host devices make file is renamed to config-host-devices.mak and the target devices mak file to config-target-devices.mak. >>>> >>>> NACK, see this thread for the previous discussion: >>>> http://lists.nongnu.org/archive/html/qemu-devel/2010-05/msg02268.html >>> >>> hmm.... so there is no interest in making the existing design actually >>> work? It's reinvent the config design or nothing? >>> >>> I'm looking to compile out all device models not relevant to my use case. >> >> That's OK, but the correct fix is to change the design of the machine >> model to something more advanced where the unwanted objects are simply >> not linked in, without any changes to board code. This is not so >> trivial and also many devices are not architecturally clean yet. > > A lot of changes are need to obtain that goal, and I am not the right > person to do them. Until that ideal design can be developed and > implemented why not take a small patch that fixes the existing design? > It's not a major change -- a very small one actually (4 files, 13 lines > modified). So far the approach has been to make changes only in line with that goal.
On 01/14/11 13:57, Blue Swirl wrote: >>> That's OK, but the correct fix is to change the design of the machine >>> model to something more advanced where the unwanted objects are simply >>> not linked in, without any changes to board code. This is not so >>> trivial and also many devices are not architecturally clean yet. >> >> A lot of changes are need to obtain that goal, and I am not the right >> person to do them. Until that ideal design can be developed and >> implemented why not take a small patch that fixes the existing design? >> It's not a major change -- a very small one actually (4 files, 13 lines >> modified). > > So far the approach has been to make changes only in line with that goal. That's a shame. I'll collapse the patch series and maintain it locally then.
On Fri, Jan 14, 2011 at 9:04 PM, David Ahern <daahern@cisco.com> wrote: > > > On 01/14/11 13:57, Blue Swirl wrote: >>>> That's OK, but the correct fix is to change the design of the machine >>>> model to something more advanced where the unwanted objects are simply >>>> not linked in, without any changes to board code. This is not so >>>> trivial and also many devices are not architecturally clean yet. >>> >>> A lot of changes are need to obtain that goal, and I am not the right >>> person to do them. Until that ideal design can be developed and >>> implemented why not take a small patch that fixes the existing design? >>> It's not a major change -- a very small one actually (4 files, 13 lines >>> modified). >> >> So far the approach has been to make changes only in line with that goal. > > That's a shame. > > I'll collapse the patch series and maintain it locally then. Patches 1, 5, 10, and 11 still look fine to me.
On 01/14/11 14:36, Blue Swirl wrote: > On Fri, Jan 14, 2011 at 9:04 PM, David Ahern <daahern@cisco.com> wrote: >> >> >> On 01/14/11 13:57, Blue Swirl wrote: >>>>> That's OK, but the correct fix is to change the design of the machine >>>>> model to something more advanced where the unwanted objects are simply >>>>> not linked in, without any changes to board code. This is not so >>>>> trivial and also many devices are not architecturally clean yet. >>>> >>>> A lot of changes are need to obtain that goal, and I am not the right >>>> person to do them. Until that ideal design can be developed and >>>> implemented why not take a small patch that fixes the existing design? >>>> It's not a major change -- a very small one actually (4 files, 13 lines >>>> modified). >>> >>> So far the approach has been to make changes only in line with that goal. >> >> That's a shame. >> >> I'll collapse the patch series and maintain it locally then. > > Patches 1, 5, 10, and 11 still look fine to me. Fine by me. The more you take, the less I have to carry locally. Sounds like patch 1 should be Stefan's patch since it pre-dates what I sent. David
On 01/14/2011 10:36 PM, Blue Swirl wrote: > On Fri, Jan 14, 2011 at 9:04 PM, David Ahern<daahern@cisco.com> wrote: >> >> >> On 01/14/11 13:57, Blue Swirl wrote: >>>>> That's OK, but the correct fix is to change the design of the machine >>>>> model to something more advanced where the unwanted objects are simply >>>>> not linked in, without any changes to board code. This is not so >>>>> trivial and also many devices are not architecturally clean yet. >>>> >>>> A lot of changes are need to obtain that goal, and I am not the right >>>> person to do them. Until that ideal design can be developed and >>>> implemented why not take a small patch that fixes the existing design? >>>> It's not a major change -- a very small one actually (4 files, 13 lines >>>> modified). >>> >>> So far the approach has been to make changes only in line with that goal. >> >> That's a shame. >> >> I'll collapse the patch series and maintain it locally then. > > Patches 1, 5, 10, and 11 still look fine to me. Patch 1 is wrong, please apply http://patchwork.ozlabs.org/patch/77021/ instead. Paolo
On Sat, Jan 15, 2011 at 4:18 PM, Paolo Bonzini <pbonzini@redhat.com> wrote: > On 01/14/2011 10:36 PM, Blue Swirl wrote: >> >> On Fri, Jan 14, 2011 at 9:04 PM, David Ahern<daahern@cisco.com> wrote: >>> >>> >>> On 01/14/11 13:57, Blue Swirl wrote: >>>>>> >>>>>> That's OK, but the correct fix is to change the design of the machine >>>>>> model to something more advanced where the unwanted objects are simply >>>>>> not linked in, without any changes to board code. This is not so >>>>>> trivial and also many devices are not architecturally clean yet. >>>>> >>>>> A lot of changes are need to obtain that goal, and I am not the right >>>>> person to do them. Until that ideal design can be developed and >>>>> implemented why not take a small patch that fixes the existing design? >>>>> It's not a major change -- a very small one actually (4 files, 13 lines >>>>> modified). >>>> >>>> So far the approach has been to make changes only in line with that >>>> goal. >>> >>> That's a shame. >>> >>> I'll collapse the patch series and maintain it locally then. >> >> Patches 1, 5, 10, and 11 still look fine to me. > > Patch 1 is wrong, please apply http://patchwork.ozlabs.org/patch/77021/ > instead. It's in: 0601740a5db12ea7ae0f2f7826f0cfb05854500a.
diff --git a/Makefile b/Makefile index 6d601ee..bce5188 100644 --- a/Makefile +++ b/Makefile @@ -38,15 +38,15 @@ DOCS= endif SUBDIR_MAKEFLAGS=$(if $(V),,--no-print-directory) -SUBDIR_DEVICES_MAK=$(patsubst %, %/config-devices.mak, $(TARGET_DIRS)) -SUBDIR_DEVICES_MAK_DEP=$(patsubst %, %/config-devices.mak.d, $(TARGET_DIRS)) +SUBDIR_DEVICES_MAK=$(patsubst %, %/config-target-devices.mak, $(TARGET_DIRS)) +SUBDIR_DEVICES_MAK_DEP=$(patsubst %, %/config-target-devices.mak.d, $(TARGET_DIRS)) -config-all-devices.mak: $(SUBDIR_DEVICES_MAK) +config-host-devices.mak: $(SUBDIR_DEVICES_MAK) $(call quiet-command,cat $(SUBDIR_DEVICES_MAK) | grep =y | sort -u > $@," GEN $@") -include $(SUBDIR_DEVICES_MAK_DEP) -%/config-devices.mak: default-configs/%.mak +%/config-target-devices.mak: default-configs/%.mak $(call quiet-command,$(SHELL) $(SRC_PATH)/make_device_config.sh $@ $<, " GEN $@") @if test -f $@; then \ if cmp -s $@.old $@; then \ @@ -67,14 +67,14 @@ config-all-devices.mak: $(SUBDIR_DEVICES_MAK) fi defconfig: - rm -f config-all-devices.mak $(SUBDIR_DEVICES_MAK) + rm -f config-host-devices.mak $(SUBDIR_DEVICES_MAK) --include config-all-devices.mak +-include config-host-devices.mak build-all: $(DOCS) $(TOOLS) recurse-all config-host.h: config-host.h-timestamp -config-host.h-timestamp: config-host.mak +config-host.h-timestamp: config-host.mak config-host-devices.mak qemu-options.def: $(SRC_PATH)/qemu-options.hx $(call quiet-command,sh $(SRC_PATH)/hxtool -h < $< > $@," GEN $@") @@ -191,7 +191,7 @@ clean: distclean: clean rm -f config-host.mak config-host.h* config-host.ld $(DOCS) qemu-options.texi qemu-img-cmds.texi qemu-monitor.texi - rm -f config-all-devices.mak + rm -f config-host-devices.mak rm -f roms/seabios/config.mak roms/vgabios/config.mak rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.dvi qemu-doc.fn qemu-doc.info qemu-doc.ky qemu-doc.log qemu-doc.pdf qemu-doc.pg qemu-doc.toc qemu-doc.tp qemu-doc.vr rm -f qemu-tech.info qemu-tech.aux qemu-tech.cp qemu-tech.dvi qemu-tech.fn qemu-tech.info qemu-tech.ky qemu-tech.log qemu-tech.pdf qemu-tech.pg qemu-tech.toc qemu-tech.tp qemu-tech.vr diff --git a/Makefile.hw b/Makefile.hw index b9181ab..3e97b0b 100644 --- a/Makefile.hw +++ b/Makefile.hw @@ -1,7 +1,7 @@ # Makefile for qemu target independent devices. include ../config-host.mak -include ../config-all-devices.mak +include ../config-host-devices.mak include config.mak include $(SRC_PATH)/rules.mak diff --git a/Makefile.target b/Makefile.target index e15b1c4..f3ed066 100644 --- a/Makefile.target +++ b/Makefile.target @@ -5,7 +5,7 @@ CONFIG_NO_PCI = $(if $(subst n,,$(CONFIG_PCI)),n,y) CONFIG_NO_KVM = $(if $(subst n,,$(CONFIG_KVM)),n,y) include ../config-host.mak -include config-devices.mak +include config-target-devices.mak include config-target.mak include $(SRC_PATH)/rules.mak ifneq ($(HWDIR),) @@ -40,7 +40,7 @@ endif kvm.o kvm-all.o vhost.o vhost_net.o: QEMU_CFLAGS+=$(KVM_CFLAGS) config-target.h: config-target.h-timestamp -config-target.h-timestamp: config-target.mak +config-target.h-timestamp: config-target.mak config-target-devices.mak ifdef CONFIG_SYSTEMTAP_TRACE stap: $(QEMU_PROG).stp diff --git a/rules.mak b/rules.mak index 6dac777..4425850 100644 --- a/rules.mak +++ b/rules.mak @@ -56,8 +56,8 @@ find-in-path = $(if $(find-string /, $1), \ %.h: %.h-timestamp @test -f $@ || cp $< $@ -%.h-timestamp: %.mak - $(call quiet-command, sh $(SRC_PATH)/create_config < $< > $@, " GEN $*.h") +%.h-timestamp: %.mak %-devices.mak + $(call quiet-command, cat $^ | $(SRC_PATH)/create_config > $@, " GEN $*.h") @cmp $@ $*.h >/dev/null 2>&1 || cp $@ $*.h # will delete the target of a rule if commands exit with a nonzero exit status
Currently, device config settings in the default-configs file are not propogated into the config*.h files. While the Makefile rules observe them through the *.mak files, the CONFIG options are not usable within the .c files. This patch adds the settings to the header files. To do that the host devices make file is renamed to config-host-devices.mak and the target devices mak file to config-target-devices.mak. Signed-off-by: David Ahern <daahern@cisco.com> --- Makefile | 16 ++++++++-------- Makefile.hw | 2 +- Makefile.target | 4 ++-- rules.mak | 4 ++-- 4 files changed, 13 insertions(+), 13 deletions(-)