Patchwork [02/11] config: settings from default-configs need to be included in header files

login
register
mail settings
Submitter David S. Ahern
Date Jan. 14, 2011, 7:12 p.m.
Message ID <1295032341-6926-3-git-send-email-daahern@cisco.com>
Download mbox | patch
Permalink /patch/79004/
State New
Headers show

Comments

David S. Ahern - Jan. 14, 2011, 7:12 p.m.
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(-)
Blue Swirl - Jan. 14, 2011, 8:17 p.m.
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
David S. Ahern - Jan. 14, 2011, 8:24 p.m.
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
Blue Swirl - Jan. 14, 2011, 8:31 p.m.
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.
David S. Ahern - Jan. 14, 2011, 8:47 p.m.
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
Blue Swirl - Jan. 14, 2011, 8:57 p.m.
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.
David S. Ahern - Jan. 14, 2011, 9:04 p.m.
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.
Blue Swirl - Jan. 14, 2011, 9:36 p.m.
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.
David S. Ahern - Jan. 14, 2011, 9:54 p.m.
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
Paolo Bonzini - Jan. 15, 2011, 4:18 p.m.
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
Blue Swirl - Jan. 15, 2011, 4:30 p.m.
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.

Patch

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