Add more CONFIG switches to make the build more modular

If the user only wants to compile targets that do not require the "or-irq" device, we should also not compile or-irq.c. Add a proper CONFIG_OR_IRQ switch to be able to choose this more flexibly.

Signed-off-by Thomas Huth <[email protected]>

---
 default-configs/arm-softmmu.mak | 1 +
 default-configs/ppc-softmmu.mak | 1 +
 hw/core/Makefile.objs           | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

default-configs/arm-softmmu.mak +1 -0

index 2420491..dc6a581 100644
@@ -4,6 +4,7 @@ include pci.mak
 include usb.mak
 CONFIG_VGA=y
 CONFIG_NAND=y
+CONFIG_OR_IRQ=y
 CONFIG_ECC=y
 CONFIG_SERIAL=y
 CONFIG_SERIAL_ISA=y

default-configs/ppc-softmmu.mak +0 -0

index 3181bbf..83235af 100644

If the user only wants to compile targets that do not require the "split-irq" device, we should also not compile split-irq.c. Add a proper CONFIG_SPLIT_IRQ switch to be able to choose this more flexibly.

Signed-off-by Thomas Huth <[email protected]>

---
 default-configs/arm-softmmu.mak | 1 +
 hw/core/Makefile.objs           | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

default-configs/arm-softmmu.mak +0 -0

index dc6a581..a3a3b66 100644

If the user only wants to compile targets that do not require the "register" device, we should also not compile register.c. Add a proper CONFIG_REGISTER switch to be able to choose this more flexibly.

Signed-off-by Thomas Huth <[email protected]>

---
 default-configs/arm-softmmu.mak        | 1 +
 default-configs/microblaze-softmmu.mak | 1 +
 hw/core/Makefile.objs                  | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

default-configs/arm-softmmu.mak +1 -0

index a3a3b66..6f2ffc1 100644
@@ -6,6 +6,7 @@ CONFIG_VGA=y
 CONFIG_NAND=y
 CONFIG_OR_IRQ=y
 CONFIG_SPLIT_IRQ=y
+CONFIG_REGISTER=y
 CONFIG_ECC=y
 CONFIG_SERIAL=y
 CONFIG_SERIAL_ISA=y

default-configs/microblaze-softmmu.mak +1 -0

index 7fca8e4..b5c5659 100644
@@ -10,3 +10,4 @@ CONFIG_XILINX_ETHLITE=y
 CONFIG_SSI=y
 CONFIG_SSI_M25P80=y
 CONFIG_XLNX_ZYNQMP=y
+CONFIG_REGISTER=y

hw/core/Makefile.objs +0 -0

index cafbe01..cb7c149 100644

The "unimplemented-device" is currently only used for one arm board.

Let's add a CONFIG switch to make sure that we only compile it when it is really necessary.

Signed-off-by Thomas Huth <[email protected]>

---
 default-configs/arm-softmmu.mak | 1 +
 hw/misc/Makefile.objs           | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

default-configs/arm-softmmu.mak +0 -0

index 6f2ffc1..dc9730f 100644

Quoted 1 line · Thomas Huth

The "unimplemented-device" is currently only used for one arm board.

? It's used in all the MPS boards, several of the imx SoCs, the nrf51 SoC used by the microbit, and by the stellaris boards.

Quoted 19 lines

Let's add a CONFIG switch to make sure that we only compile it when it is really necessary.

Signed-off-by Thomas Huth <[email protected]>

---
 default-configs/arm-softmmu.mak | 1 +
 hw/misc/Makefile.objs           | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

default-configs/arm-softmmu.mak +1 -0

index 6f2ffc1..dc9730f 100644
@@ -7,6 +7,7 @@ CONFIG_NAND=y
 CONFIG_OR_IRQ=y
 CONFIG_SPLIT_IRQ=y
 CONFIG_REGISTER=y
+CONFIG_UNIMP=y
 CONFIG_ECC=y

default-configs/arm-softmmu.mak CONFIG_NAND=y · line 13

Quoted 2 lines

default-configs/arm-softmmu.mak +0 -0

 CONFIG_SERIAL=y
 CONFIG_SERIAL_ISA=y

This seems awkward to me. The 'unimplemented' device is supposed to be an entirely generic thing usable in any board model. If we only turn it on in the arm-softmmu.mak then it means faffing around with the default-configs/ whenever it gets used in a different architecture.

In particular, there's a pull request on the list that uses it in a sparc board, so this patch will break compile on sparc once that pullreq lands.

Anyway, it's also not only about speeding up the compilation process for people who don't want to use the corresponding targets, this is also very useful for downstream distributions of QEMU who want to make sure to not compile-in more devices than urgently needed. For example we disable this device here and the others in downstream RHEL version of QEMU, and I guess it might be interesting for nemu, too. So having more flexibility here in the Makefiles would be really great to decrease the burden with downstream-specific patches...

I think if we want to support this for downstreams we need to look at something better than the default-configs/ mechanism for it. (Perhaps the kconfig-alike Paolo mentioned in a previous thread?)

My dividing line for "should something go in a specific architecture's default-configs/ list" is "is this an SoC or real piece of hardware that is naturally limited to one or a few SoCs".

Quoted 25 lines · Peter Maydell

Quoted 1 line · Thomas Huth

The "unimplemented-device" is currently only used for one arm board.

? It's used in all the MPS boards, several of the imx SoCs, the nrf51 SoC used by the microbit, and by the stellaris boards.

Quoted 19 lines

Let's add a CONFIG switch to make sure that we only compile it when it is really necessary.

Signed-off-by Thomas Huth <[email protected]>

---
 default-configs/arm-softmmu.mak | 1 +
 hw/misc/Makefile.objs           | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

default-configs/arm-softmmu.mak +1 -0

index 6f2ffc1..dc9730f 100644
@@ -7,6 +7,7 @@ CONFIG_NAND=y
 CONFIG_OR_IRQ=y
 CONFIG_SPLIT_IRQ=y
 CONFIG_REGISTER=y
+CONFIG_UNIMP=y
 CONFIG_ECC=y

Quoted 8 lines

default-configs/arm-softmmu.mak CONFIG_NAND=y · line 13

Quoted 2 lines

default-configs/arm-softmmu.mak +0 -0

 CONFIG_SERIAL=y
 CONFIG_SERIAL_ISA=y

This seems awkward to me. The 'unimplemented' device is supposed to be an entirely generic thing usable in any board model. If we only turn it on in the arm-softmmu.mak then it means faffing around with the default-configs/ whenever it gets used in a different architecture.

The device has been added 1.5 years ago, and so far no other target is using it yet. So it's very seldom that you've got to expect any changes, I think.

Anyway, it's also not only about speeding up the compilation process for people who don't want to use the corresponding targets, this is also very useful for downstream distributions of QEMU who want to make sure to not compile-in more devices than urgently needed. For example we disable this device here and the others in downstream RHEL version of QEMU, and I guess it might be interesting for nemu, too. So having more flexibility here in the Makefiles would be really great to decrease the burden with downstream-specific patches...

Quoted 3 lines

In particular, there's a pull request on the list that uses it in a sparc board, so this patch will break compile on sparc once that pullreq lands.

Ok, then please disregard this patch here, but it would be great if you could still consider the other patches of this series.

Thomas

First because I'm using it heavily on MIPS and PPC boards, when no datashits are available.
I'll submit that during the next merge window, although the MIPS tree seems now reluctant to that kind of hobbyist work.

Second, because it is very clean when you implement a SoC to first start with an empty UNIMP region and a cpu core,
then declare the mmio regions for each device (still UNIMP), then you can slowly add devices one at a time.
This let you (me, so far) push at most a dozen of tiny patches in a working series, instead of a small series of a dozen of huge patches, or a series of 100 tiny patches.

Quoted 6 lines · Philippe Mathieu-Daudé

First because I'm using it heavily on MIPS and PPC boards, when no datashits are available.
I'll submit that during the next merge window, although the MIPS tree seems now reluctant to that kind of hobbyist work.

Quoted 7 lines

Second, because it is very clean when you implement a SoC to first start with an empty UNIMP region and a cpu core,
then declare the mmio regions for each device (still UNIMP), then you can slowly add devices one at a time.
This let you (me, so far) push at most a dozen of tiny patches in a working series, instead of a small series of a dozen of huge patches, or a series of 100 tiny patches.

I don't see however why it's a problem to add/remove CONFIG_UNIMP to default-configs though (in the Kconfig world the board would "select UNIMP").

Quoted 15 lines · Paolo Bonzini

Quoted 6 lines · Philippe Mathieu-Daudé

First because I'm using it heavily on MIPS and PPC boards, when no datashits are available.
I'll submit that during the next merge window, although the MIPS tree seems now reluctant to that kind of hobbyist work.

Quoted 7 lines

Second, because it is very clean when you implement a SoC to first start with an empty UNIMP region and a cpu core,
then declare the mmio regions for each device (still UNIMP), then you can slowly add devices one at a time.
This let you (me, so far) push at most a dozen of tiny patches in a working series, instead of a small series of a dozen of huge patches, or a series of 100 tiny patches.

Quoted 3 lines

I don't see however why it's a problem to add/remove CONFIG_UNIMP to default-configs though (in the Kconfig world the board would "select UNIMP").

Well, it's extra friction for people writing new board models, and the benefit of having CONFIG_UNIMP is all to downstream redistributors, not to upstream...

I'm not vetoing this patchset, but I do think that if RedHat wants to distribute significantly-cut-down binaries then it would be worth working on a mechanism for making that more conveniently doable, rather than just hacking up the very creaky default-configs/ stuff.

This device is not user-creatable and currently only used for the "alpha" target. So if the user does not want to compile alpha-softmmu, we should also not compile this device. Add a proper config switch to be able to compile this more flexibly.

Signed-off-by Thomas Huth <[email protected]>

---
 default-configs/alpha-softmmu.mak | 1 +
 hw/isa/Makefile.objs              | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

default-configs/alpha-softmmu.mak +1 -0

index bbe361f..eb58b40 100644
@@ -19,3 +19,4 @@ CONFIG_IDE_CMD646=y
 CONFIG_I8259=y
 CONFIG_MC146818RTC=y
 CONFIG_ISA_TESTDEV=y
+CONFIG_SMC37C669=y

hw/isa/Makefile.objs +0 -0

index 83e06f6..9e106df 100644

Quoted 25 lines · Thomas Huth

This device is not user-creatable and currently only used for the "alpha" target. So if the user does not want to compile alpha-softmmu, we should also not compile this device. Add a proper config switch to be able to compile this more flexibly.

Signed-off-by Thomas Huth <[email protected]>

---
 default-configs/alpha-softmmu.mak | 1 +
 hw/isa/Makefile.objs              | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

default-configs/alpha-softmmu.mak +1 -0

index bbe361f..eb58b40 100644
@@ -19,3 +19,4 @@ CONFIG_IDE_CMD646=y
 CONFIG_I8259=y
 CONFIG_MC146818RTC=y
 CONFIG_ISA_TESTDEV=y
+CONFIG_SMC37C669=y

hw/isa/Makefile.objs +0 -0

index 83e06f6..9e106df 100644

hw/isa/Makefile.objs line 8

Quoted 9 lines

hw/isa/Makefile.objs +2 -1

@@ -1,9 +1,10 @@
 common-obj-$(CONFIG_ISA_BUS) += isa-bus.o
-common-obj-$(CONFIG_ISA_BUS) += isa-superio.o smc37c669-superio.o
+common-obj-$(CONFIG_ISA_BUS) += isa-superio.o
 common-obj-$(CONFIG_APM) += apm.o
 common-obj-$(CONFIG_I82378) += i82378.o
 common-obj-$(CONFIG_PC87312) += pc87312.o
 common-obj-$(CONFIG_PIIX4) += piix4.o
 common-obj-$(CONFIG_VT82C686) += vt82c686.o
+common-obj-$(CONFIG_SMC37C669) += smc37c669-superio.o

Reviewed-by Peter Maydell <[email protected]>

Should isa-superio.o also go in its own config flag?

thanks
-- PMM

Quoted 1 line · Peter Maydell

Should isa-superio.o also go in its own config flag?

It could be, but pc87312/smc37c669/vt82c686 inherit of TYPE_ISA_SUPERIO so would require something like:

common-obj-$(call land,$(CONFIG_ISA_SUPERIO),$(CONFIG_PC87312)) \
            += pc87312.o
common-obj-$(call land,$(CONFIG_ISA_SUPERIO),$(CONFIG_VT82C686)) \
            += vt82c686.o
common-obj-$(call land,$(CONFIG_ISA_SUPERIO),$(CONFIG_SMC37C669)) \
            += smc37c669-superio.o