[PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the type_init
function that calls type_register_static(). A later change needs to pass a
target mask into that registration, and the macros have no parameter for it.
This series expands every caller first, with no behavior change, so the
follow-up only replaces the type_register_static() call.

Each machine file gains a class_init function, a TypeInfo, and a type_init
function that calls type_register_static(). The last patch removes
DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.

Yonggang Luo (15):
  hw/alpha: expand DEFINE_MACHINE in dp264.c
  hw/m68k: expand DEFINE_MACHINE for M68K machines
  hw/microblaze: expand DEFINE_MACHINE for MicroBlaze
  hw/tricore: expand DEFINE_MACHINE in tricore_testboard.c
  hw/arm: expand DEFINE_MACHINE for ARM machines
  hw/riscv: expand DEFINE_MACHINE for RISC-V machines
  hw/core/null-machine: expand DEFINE_MACHINE
  hw/mips: expand DEFINE_MACHINE for MIPS machines
  hw/ppc: expand DEFINE_MACHINE for PowerPC machines
  hw/sh4: expand DEFINE_MACHINE in r2d.c
  hw/sparc: expand DEFINE_MACHINE in leon3.c
  hw/xenpv: expand DEFINE_MACHINE in xen_machine_pv.c
  hw/xtensa: expand DEFINE_MACHINE in sim.c
  hw/xtensa: expand DEFINE_MACHINE in virt.c
  hw/core/boards: remove unused DEFINE_MACHINE* macros

 hw/alpha/dp264.c                    | 18 +++++++++--
 hw/arm/bananapi_m2u.c               | 18 +++++++++--
 hw/arm/cubieboard.c                 | 19 +++++++++---
 hw/arm/digic_boards.c               | 18 +++++++++--
 hw/arm/imx25_pdk.c                  | 18 +++++++++--
 hw/arm/imx8mm-evk.c                 | 20 +++++++++---
 hw/arm/integratorcp.c               | 14 ++++++---
 hw/arm/kzm.c                        | 18 +++++++++--
 hw/arm/max78000fthr.c               | 17 ++++++++--
 hw/arm/mcimx6ul-evk.c               | 18 +++++++++--
 hw/arm/mcimx7d-sabre.c              | 20 +++++++++---
 hw/arm/msf2-som.c                   | 17 ++++++++--
 hw/arm/netduino2.c                  | 17 ++++++++--
 hw/arm/netduinoplus2.c              | 17 ++++++++--
 hw/arm/olimex-stm32-h405.c          | 18 +++++++++--
 hw/arm/orangepi.c                   | 19 +++++++++---
 hw/arm/stm32vldiscovery.c           | 18 +++++++++--
 hw/core/null-machine.c              | 18 +++++++++--
 hw/m68k/an5206.c                    | 18 +++++++++--
 hw/m68k/mcf5208.c                   | 18 +++++++++--
 hw/microblaze/petalogix_ml605_mmu.c | 19 ++++++++++--
 hw/microblaze/xlnx-zynqmp-pmu.c     | 19 ++++++++++--
 hw/mips/boston.c                    | 18 +++++++++--
 hw/mips/fuloong2e.c                 | 18 +++++++++--
 hw/mips/malta.c                     | 12 ++++++--
 hw/ppc/amigaone.c                   | 18 +++++++++--
 hw/ppc/pegasos.c                    | 21 ++++++++-----
 hw/ppc/ppc440_bamboo.c              | 18 +++++++++--
 hw/ppc/prep.c                       | 18 +++++++++--
 hw/ppc/sam460ex.c                   | 18 +++++++++--
 hw/ppc/virtex_ml507.c               | 18 +++++++++--
 hw/riscv/boston-aia.c               | 18 +++++++++--
 hw/riscv/microblaze-v-generic.c     | 18 +++++++++--
 hw/sh4/r2d.c                        | 18 +++++++++--
 hw/sparc/leon3.c                    | 18 +++++++++--
 hw/tricore/tricore_testboard.c      | 18 +++++++++--
 hw/xenpv/xen_machine_pv.c           | 18 +++++++++--
 hw/xtensa/sim.c                     | 18 +++++++++--
 hw/xtensa/virt.c                    | 18 +++++++++--
 include/hw/core/boards.h            | 48 -----------------------------
 40 files changed, 605 insertions(+), 142 deletions(-)

-- 
2.55.0.windows.3

[PATCH 01/15] hw/alpha: expand DEFINE_MACHINE in dp264.c

[Yonggang Luo]

Expand DEFINE_MACHINE() for the clipper machine to clipper_machine_typeinfo
and clipper_machine_register_types() calling type_register_static().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/alpha/dp264.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
index f928e0cee82..83e9a0853c1 100644
--- a/hw/alpha/dp264.c
+++ b/hw/alpha/dp264.c
@@ -201,8 +201,10 @@ static void clipper_init(MachineState *machine)
     }
 }
 
-static void clipper_machine_init(MachineClass *mc)
+static void clipper_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "Alpha DP264/CLIPPER";
     mc->init = clipper_init;
     mc->block_default_type = IF_IDE;
@@ -213,4 +215,16 @@ static void clipper_machine_init(MachineClass *mc)
     mc->default_nic = "e1000";
 }
 
-DEFINE_MACHINE("clipper", clipper_machine_init)
+static const TypeInfo clipper_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("clipper"),
+    .parent     = TYPE_MACHINE,
+    .class_init = clipper_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void clipper_machine_register_types(void)
+{
+    type_register_static(&clipper_machine_typeinfo);
+}
+
+type_init(clipper_machine_register_types)
-- 
2.55.0.windows.3

[PATCH 02/15] hw/m68k: expand DEFINE_MACHINE for M68K machines

[Yonggang Luo]

Expand DEFINE_MACHINE() in hw/m68k/an5206.c and hw/m68k/mcf5208.c to
explicit TypeInfo and type_init() functions calling
type_register_static().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/m68k/an5206.c  | 18 ++++++++++++++++--
 hw/m68k/mcf5208.c | 18 ++++++++++++++++--
 2 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/hw/m68k/an5206.c b/hw/m68k/an5206.c
index 1acd2fbdfb3..8838563cb3e 100644
--- a/hw/m68k/an5206.c
+++ b/hw/m68k/an5206.c
@@ -93,12 +93,26 @@ static void an5206_init(MachineState *machine)
     env->pc = entry;
 }
 
-static void an5206_machine_init(MachineClass *mc)
+static void an5206_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "Arnewsh 5206";
     mc->init = an5206_init;
     mc->default_cpu_type = M68K_CPU_TYPE_NAME("m5206");
     mc->default_ram_id = "an5206.ram";
 }
 
-DEFINE_MACHINE("an5206", an5206_machine_init)
+static const TypeInfo an5206_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("an5206"),
+    .parent     = TYPE_MACHINE,
+    .class_init = an5206_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void an5206_machine_register_types(void)
+{
+    type_register_static(&an5206_machine_typeinfo);
+}
+
+type_init(an5206_machine_register_types)
diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
index a8068c91f24..5c3ab48ddde 100644
--- a/hw/m68k/mcf5208.c
+++ b/hw/m68k/mcf5208.c
@@ -389,8 +389,10 @@ static void mcf5208evb_init(MachineState *machine)
     env->pc = entry;
 }
 
-static void mcf5208evb_machine_init(MachineClass *mc)
+static void mcf5208evb_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "MCF5208EVB";
     mc->init = mcf5208evb_init;
     mc->is_default = true;
@@ -398,4 +400,16 @@ static void mcf5208evb_machine_init(MachineClass *mc)
     mc->default_ram_id = "mcf5208.ram";
 }
 
-DEFINE_MACHINE("mcf5208evb", mcf5208evb_machine_init)
+static const TypeInfo mcf5208evb_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("mcf5208evb"),
+    .parent     = TYPE_MACHINE,
+    .class_init = mcf5208evb_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void mcf5208evb_machine_register_types(void)
+{
+    type_register_static(&mcf5208evb_machine_typeinfo);
+}
+
+type_init(mcf5208evb_machine_register_types)
-- 
2.55.0.windows.3

[PATCH 03/15] hw/microblaze: expand DEFINE_MACHINE for MicroBlaze

[Yonggang Luo]

Expand DEFINE_MACHINE() in hw/microblaze/petalogix_ml605_mmu.c and
hw/microblaze/xlnx-zynqmp-pmu.c to explicit TypeInfo and type_init()
functions calling type_register_static().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/microblaze/petalogix_ml605_mmu.c | 19 +++++++++++++++++--
 hw/microblaze/xlnx-zynqmp-pmu.c     | 19 +++++++++++++++++--
 2 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/hw/microblaze/petalogix_ml605_mmu.c b/hw/microblaze/petalogix_ml605_mmu.c
index 8f9f54ff1e2..393eeba76f5 100644
--- a/hw/microblaze/petalogix_ml605_mmu.c
+++ b/hw/microblaze/petalogix_ml605_mmu.c
@@ -214,10 +214,25 @@ petalogix_ml605_init(MachineState *machine)
 
 }
 
-static void petalogix_ml605_machine_init(MachineClass *mc)
+static void petalogix_ml605_machine_class_init(ObjectClass *oc,
+                                               const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "PetaLogix linux refdesign for xilinx ml605 (little endian)";
     mc->init = petalogix_ml605_init;
 }
 
-DEFINE_MACHINE("petalogix-ml605", petalogix_ml605_machine_init)
+static const TypeInfo petalogix_ml605_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("petalogix-ml605"),
+    .parent     = TYPE_MACHINE,
+    .class_init = petalogix_ml605_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void petalogix_ml605_machine_register_types(void)
+{
+    type_register_static(&petalogix_ml605_machine_typeinfo);
+}
+
+type_init(petalogix_ml605_machine_register_types)
diff --git a/hw/microblaze/xlnx-zynqmp-pmu.c b/hw/microblaze/xlnx-zynqmp-pmu.c
index 00154236bf8..d3ade9faeee 100644
--- a/hw/microblaze/xlnx-zynqmp-pmu.c
+++ b/hw/microblaze/xlnx-zynqmp-pmu.c
@@ -179,10 +179,25 @@ static void xlnx_zynqmp_pmu_init(MachineState *machine)
                            NULL);
 }
 
-static void xlnx_zynqmp_pmu_machine_init(MachineClass *mc)
+static void xlnx_zynqmp_pmu_machine_class_init(ObjectClass *oc,
+                                               const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "Xilinx ZynqMP PMU machine (little endian)";
     mc->init = xlnx_zynqmp_pmu_init;
 }
 
-DEFINE_MACHINE("xlnx-zynqmp-pmu", xlnx_zynqmp_pmu_machine_init)
+static const TypeInfo xlnx_zynqmp_pmu_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("xlnx-zynqmp-pmu"),
+    .parent     = TYPE_MACHINE,
+    .class_init = xlnx_zynqmp_pmu_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void xlnx_zynqmp_pmu_machine_register_types(void)
+{
+    type_register_static(&xlnx_zynqmp_pmu_machine_typeinfo);
+}
+
+type_init(xlnx_zynqmp_pmu_machine_register_types)
-- 
2.55.0.windows.3

[PATCH 04/15] hw/tricore: expand DEFINE_MACHINE in tricore_testboard.c

[Yonggang Luo]

Expand DEFINE_MACHINE() in hw/tricore/tricore_testboard.c to
ttb_machine_typeinfo and ttb_machine_register_types() calling
type_register_static().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/tricore/tricore_testboard.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/hw/tricore/tricore_testboard.c b/hw/tricore/tricore_testboard.c
index d5d796c8eec..2a25f090520 100644
--- a/hw/tricore/tricore_testboard.c
+++ b/hw/tricore/tricore_testboard.c
@@ -106,11 +106,25 @@ static void tricoreboard_init(MachineState *machine)
     tricore_testboard_init(machine, 0x183);
 }
 
-static void ttb_machine_init(MachineClass *mc)
+static void ttb_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "a minimal TriCore board";
     mc->init = tricoreboard_init;
     mc->default_cpu_type = TRICORE_CPU_TYPE_NAME("tc1796");
 }
 
-DEFINE_MACHINE("tricore_testboard", ttb_machine_init)
+static const TypeInfo ttb_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("tricore_testboard"),
+    .parent     = TYPE_MACHINE,
+    .class_init = ttb_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void ttb_machine_register_types(void)
+{
+    type_register_static(&ttb_machine_typeinfo);
+}
+
+type_init(ttb_machine_register_types)
-- 
2.55.0.windows.3

[PATCH 05/15] hw/arm: expand DEFINE_MACHINE for ARM machines

[Yonggang Luo]

Expand DEFINE_MACHINE() and DEFINE_MACHINE_EXTENDED() to explicit
TypeInfo and type_register_static() calls for the ARM machine types,
reusing integratorcp_register_types() in hw/arm/integratorcp.c.

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/arm/bananapi_m2u.c      | 18 +++++++++++++++---
 hw/arm/cubieboard.c        | 19 +++++++++++++++----
 hw/arm/digic_boards.c      | 18 ++++++++++++++++--
 hw/arm/imx25_pdk.c         | 18 ++++++++++++++++--
 hw/arm/imx8mm-evk.c        | 20 ++++++++++++++++----
 hw/arm/integratorcp.c      | 14 ++++++++++----
 hw/arm/kzm.c               | 18 ++++++++++++++++--
 hw/arm/max78000fthr.c      | 17 +++++++++++++++--
 hw/arm/mcimx6ul-evk.c      | 18 ++++++++++++++++--
 hw/arm/mcimx7d-sabre.c     | 20 ++++++++++++++++----
 hw/arm/msf2-som.c          | 17 +++++++++++++++--
 hw/arm/netduino2.c         | 17 +++++++++++++++--
 hw/arm/netduinoplus2.c     | 17 +++++++++++++++--
 hw/arm/olimex-stm32-h405.c | 18 ++++++++++++++++--
 hw/arm/orangepi.c          | 19 +++++++++++++++----
 hw/arm/stm32vldiscovery.c  | 18 ++++++++++++++++--
 16 files changed, 243 insertions(+), 43 deletions(-)

diff --git a/hw/arm/bananapi_m2u.c b/hw/arm/bananapi_m2u.c
index ccf60ba2955..ad30e34d718 100644
--- a/hw/arm/bananapi_m2u.c
+++ b/hw/arm/bananapi_m2u.c
@@ -133,8 +133,9 @@ static void bpim2u_init(MachineState *machine)
     arm_load_kernel(&r40->cpus[0], machine, &bpms->bootinfo);
 }
 
-static void bpim2u_machine_init(MachineClass *mc)
+static void bpim2u_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
     static const char * const valid_cpu_types[] = {
         ARM_CPU_TYPE_NAME("cortex-a7"),
         NULL
@@ -152,5 +153,16 @@ static void bpim2u_machine_init(MachineClass *mc)
     mc->auto_create_sdcard = true;
 }
 
-DEFINE_MACHINE_EXTENDED("bpim2u", MACHINE, Bpim2uMachineState,
-                        bpim2u_machine_init, false, false, NULL)
+static const TypeInfo bpim2u_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("bpim2u"),
+    .parent     = TYPE_MACHINE,
+    .class_init = bpim2u_machine_class_init,
+    .instance_size = sizeof(Bpim2uMachineState),
+};
+
+static void bpim2u_machine_register_types(void)
+{
+    type_register_static(&bpim2u_machine_typeinfo);
+}
+
+type_init(bpim2u_machine_register_types)
diff --git a/hw/arm/cubieboard.c b/hw/arm/cubieboard.c
index e4fef9cd76b..66610d495bc 100644
--- a/hw/arm/cubieboard.c
+++ b/hw/arm/cubieboard.c
@@ -113,8 +113,9 @@ static void cubieboard_init(MachineState *machine)
     arm_load_kernel(&a10->cpu, machine, &cbs->bootinfo);
 }
 
-static void cubieboard_machine_init(MachineClass *mc)
+static void cubieboard_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
     static const char * const valid_cpu_types[] = {
         ARM_CPU_TYPE_NAME("cortex-a8"),
         NULL
@@ -132,6 +133,16 @@ static void cubieboard_machine_init(MachineClass *mc)
     mc->auto_create_sdcard = true;
 }
 
-DEFINE_MACHINE_EXTENDED("cubieboard", MACHINE, CubieboardMachineState,
-                        cubieboard_machine_init, false, false,
-                        NULL)
+static const TypeInfo cubieboard_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("cubieboard"),
+    .parent     = TYPE_MACHINE,
+    .class_init = cubieboard_machine_class_init,
+    .instance_size = sizeof(CubieboardMachineState),
+};
+
+static void cubieboard_machine_register_types(void)
+{
+    type_register_static(&cubieboard_machine_typeinfo);
+}
+
+type_init(cubieboard_machine_register_types)
diff --git a/hw/arm/digic_boards.c b/hw/arm/digic_boards.c
index 90c19106ad0..49e71f71e97 100644
--- a/hw/arm/digic_boards.c
+++ b/hw/arm/digic_boards.c
@@ -136,8 +136,10 @@ static void canon_a1100_init(MachineState *machine)
     digic4_board_init(machine, &digic4_board_canon_a1100);
 }
 
-static void canon_a1100_machine_init(MachineClass *mc)
+static void canon_a1100_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "Canon PowerShot A1100 IS (ARM946)";
     mc->init = &canon_a1100_init;
     mc->ignore_memory_transaction_failures = true;
@@ -145,4 +147,16 @@ static void canon_a1100_machine_init(MachineClass *mc)
     mc->default_ram_id = "ram";
 }
 
-DEFINE_MACHINE("canon-a1100", canon_a1100_machine_init)
+static const TypeInfo canon_a1100_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("canon-a1100"),
+    .parent     = TYPE_MACHINE,
+    .class_init = canon_a1100_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void canon_a1100_machine_register_types(void)
+{
+    type_register_static(&canon_a1100_machine_typeinfo);
+}
+
+type_init(canon_a1100_machine_register_types)
diff --git a/hw/arm/imx25_pdk.c b/hw/arm/imx25_pdk.c
index a33050788c3..546d8002662 100644
--- a/hw/arm/imx25_pdk.c
+++ b/hw/arm/imx25_pdk.c
@@ -140,8 +140,10 @@ static void imx25_pdk_init(MachineState *machine)
     }
 }
 
-static void imx25_pdk_machine_init(MachineClass *mc)
+static void imx25_pdk_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "ARM i.MX25 PDK board (ARM926)";
     mc->init = imx25_pdk_init;
     mc->ignore_memory_transaction_failures = true;
@@ -149,4 +151,16 @@ static void imx25_pdk_machine_init(MachineClass *mc)
     mc->auto_create_sdcard = true;
 }
 
-DEFINE_MACHINE("imx25-pdk", imx25_pdk_machine_init)
+static const TypeInfo imx25_pdk_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("imx25-pdk"),
+    .parent     = TYPE_MACHINE,
+    .class_init = imx25_pdk_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void imx25_pdk_machine_register_types(void)
+{
+    type_register_static(&imx25_pdk_machine_typeinfo);
+}
+
+type_init(imx25_pdk_machine_register_types)
diff --git a/hw/arm/imx8mm-evk.c b/hw/arm/imx8mm-evk.c
index 6de0d9c4a2e..ba1b603081b 100644
--- a/hw/arm/imx8mm-evk.c
+++ b/hw/arm/imx8mm-evk.c
@@ -122,8 +122,10 @@ static const char *imx8mm_evk_get_default_cpu_type(const MachineState *ms)
     return ARM_CPU_TYPE_NAME("cortex-a53");
 }
 
-static void imx8mm_evk_machine_init(MachineClass *mc)
+static void imx8mm_evk_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "NXP i.MX 8MM EVK Board";
     mc->init = imx8mm_evk_init;
     mc->max_cpus = FSL_IMX8MM_NUM_CPUS;
@@ -133,6 +135,16 @@ static void imx8mm_evk_machine_init(MachineClass *mc)
     mc->get_default_cpu_type = imx8mm_evk_get_default_cpu_type;
 }
 
-DEFINE_MACHINE_EXTENDED("imx8mm-evk", MACHINE, Imx8mmEvkMachineState,
-                        imx8mm_evk_machine_init, false, false,
-                        NULL)
+static const TypeInfo imx8mm_evk_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("imx8mm-evk"),
+    .parent     = TYPE_MACHINE,
+    .class_init = imx8mm_evk_machine_class_init,
+    .instance_size = sizeof(Imx8mmEvkMachineState),
+};
+
+static void imx8mm_evk_machine_register_types(void)
+{
+    type_register_static(&imx8mm_evk_machine_typeinfo);
+}
+
+type_init(imx8mm_evk_machine_register_types)
diff --git a/hw/arm/integratorcp.c b/hw/arm/integratorcp.c
index b766edeeee1..9736795b243 100644
--- a/hw/arm/integratorcp.c
+++ b/hw/arm/integratorcp.c
@@ -691,8 +691,10 @@ static void integratorcp_init(MachineState *machine)
     arm_load_kernel(cpu, machine, &icms->bootinfo);
 }
 
-static void integratorcp_machine_init(MachineClass *mc)
+static void integratorcp_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "ARM Integrator/CP (ARM926EJ-S)";
     mc->init = integratorcp_init;
     mc->ignore_memory_transaction_failures = true;
@@ -703,9 +705,12 @@ static void integratorcp_machine_init(MachineClass *mc)
     machine_add_audiodev_property(mc);
 }
 
-DEFINE_MACHINE_EXTENDED("integratorcp", MACHINE, IntegratorcpMachineState,
-                        integratorcp_machine_init, false, false,
-                        NULL)
+static const TypeInfo integratorcp_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("integratorcp"),
+    .parent     = TYPE_MACHINE,
+    .class_init = integratorcp_machine_class_init,
+    .instance_size = sizeof(IntegratorcpMachineState),
+};
 
 static const Property core_properties[] = {
     DEFINE_PROP_UINT32("memsz", IntegratorCMState, memsz, 0),
@@ -760,6 +765,7 @@ static const TypeInfo icp_ctrl_regs_info = {
 
 static void integratorcp_register_types(void)
 {
+    type_register_static(&integratorcp_machine_typeinfo);
     type_register_static(&icp_pic_info);
     type_register_static(&core_info);
     type_register_static(&icp_ctrl_regs_info);
diff --git a/hw/arm/kzm.c b/hw/arm/kzm.c
index e9cc53ce017..6196d40cb2e 100644
--- a/hw/arm/kzm.c
+++ b/hw/arm/kzm.c
@@ -129,12 +129,26 @@ static void kzm_init(MachineState *machine)
     }
 }
 
-static void kzm_machine_init(MachineClass *mc)
+static void kzm_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "ARM KZM Emulation Baseboard (ARM1136)";
     mc->init = kzm_init;
     mc->ignore_memory_transaction_failures = true;
     mc->default_ram_id = "kzm.ram";
 }
 
-DEFINE_MACHINE("kzm", kzm_machine_init)
+static const TypeInfo kzm_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("kzm"),
+    .parent     = TYPE_MACHINE,
+    .class_init = kzm_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void kzm_machine_register_types(void)
+{
+    type_register_static(&kzm_machine_typeinfo);
+}
+
+type_init(kzm_machine_register_types)
diff --git a/hw/arm/max78000fthr.c b/hw/arm/max78000fthr.c
index ed50bb91979..33c1ccbd3c8 100644
--- a/hw/arm/max78000fthr.c
+++ b/hw/arm/max78000fthr.c
@@ -35,8 +35,9 @@ static void max78000_init(MachineState *machine)
                        0x00000000, FLASH_SIZE);
 }
 
-static void max78000_machine_init(MachineClass *mc)
+static void max78000_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
     static const char * const valid_cpu_types[] = {
         ARM_CPU_TYPE_NAME("cortex-m4"),
         NULL
@@ -47,4 +48,16 @@ static void max78000_machine_init(MachineClass *mc)
     mc->valid_cpu_types = valid_cpu_types;
 }
 
-DEFINE_MACHINE("max78000fthr", max78000_machine_init)
+static const TypeInfo max78000_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("max78000fthr"),
+    .parent     = TYPE_MACHINE,
+    .class_init = max78000_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void max78000_machine_register_types(void)
+{
+    type_register_static(&max78000_machine_typeinfo);
+}
+
+type_init(max78000_machine_register_types)
diff --git a/hw/arm/mcimx6ul-evk.c b/hw/arm/mcimx6ul-evk.c
index 53d221b4a9a..a4cdaac1176 100644
--- a/hw/arm/mcimx6ul-evk.c
+++ b/hw/arm/mcimx6ul-evk.c
@@ -68,8 +68,10 @@ static void mcimx6ul_evk_init(MachineState *machine)
     }
 }
 
-static void mcimx6ul_evk_machine_init(MachineClass *mc)
+static void mcimx6ul_evk_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "Freescale i.MX6UL Evaluation Kit (Cortex-A7)";
     mc->init = mcimx6ul_evk_init;
     mc->max_cpus = FSL_IMX6UL_NUM_CPUS;
@@ -78,4 +80,16 @@ static void mcimx6ul_evk_machine_init(MachineClass *mc)
     mc->auto_create_sdcard = true;
 }
 
-DEFINE_MACHINE("mcimx6ul-evk", mcimx6ul_evk_machine_init)
+static const TypeInfo mcimx6ul_evk_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("mcimx6ul-evk"),
+    .parent     = TYPE_MACHINE,
+    .class_init = mcimx6ul_evk_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void mcimx6ul_evk_machine_register_types(void)
+{
+    type_register_static(&mcimx6ul_evk_machine_typeinfo);
+}
+
+type_init(mcimx6ul_evk_machine_register_types)
diff --git a/hw/arm/mcimx7d-sabre.c b/hw/arm/mcimx7d-sabre.c
index 55c23061b0a..5a868af6c1f 100644
--- a/hw/arm/mcimx7d-sabre.c
+++ b/hw/arm/mcimx7d-sabre.c
@@ -76,8 +76,10 @@ static void mcimx7d_sabre_init(MachineState *machine)
     }
 }
 
-static void mcimx7d_sabre_machine_init(MachineClass *mc)
+static void mcimx7d_sabre_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "Freescale i.MX7 DUAL SABRE (Cortex-A7)";
     mc->init = mcimx7d_sabre_init;
     mc->max_cpus = FSL_IMX7_NUM_CPUS;
@@ -87,6 +89,16 @@ static void mcimx7d_sabre_machine_init(MachineClass *mc)
     mc->auto_create_sdcard = true;
 }
 
-DEFINE_MACHINE_EXTENDED("mcimx7d-sabre", MACHINE, Mcimx7dSabreMachineState,
-                        mcimx7d_sabre_machine_init, false, false,
-                        NULL)
+static const TypeInfo mcimx7d_sabre_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("mcimx7d-sabre"),
+    .parent     = TYPE_MACHINE,
+    .class_init = mcimx7d_sabre_machine_class_init,
+    .instance_size = sizeof(Mcimx7dSabreMachineState),
+};
+
+static void mcimx7d_sabre_machine_register_types(void)
+{
+    type_register_static(&mcimx7d_sabre_machine_typeinfo);
+}
+
+type_init(mcimx7d_sabre_machine_register_types)
diff --git a/hw/arm/msf2-som.c b/hw/arm/msf2-som.c
index 1372d7f628a..938ccab05c4 100644
--- a/hw/arm/msf2-som.c
+++ b/hw/arm/msf2-som.c
@@ -96,8 +96,9 @@ static void emcraft_sf2_s2s010_init(MachineState *machine)
                        0, soc->envm_size);
 }
 
-static void emcraft_sf2_machine_init(MachineClass *mc)
+static void emcraft_sf2_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
     static const char * const valid_cpu_types[] = {
         ARM_CPU_TYPE_NAME("cortex-m3"),
         NULL
@@ -108,4 +109,16 @@ static void emcraft_sf2_machine_init(MachineClass *mc)
     mc->valid_cpu_types = valid_cpu_types;
 }
 
-DEFINE_MACHINE("emcraft-sf2", emcraft_sf2_machine_init)
+static const TypeInfo emcraft_sf2_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("emcraft-sf2"),
+    .parent     = TYPE_MACHINE,
+    .class_init = emcraft_sf2_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void emcraft_sf2_machine_register_types(void)
+{
+    type_register_static(&emcraft_sf2_machine_typeinfo);
+}
+
+type_init(emcraft_sf2_machine_register_types)
diff --git a/hw/arm/netduino2.c b/hw/arm/netduino2.c
index 0db8798b4bd..3f95672670e 100644
--- a/hw/arm/netduino2.c
+++ b/hw/arm/netduino2.c
@@ -52,8 +52,9 @@ static void netduino2_init(MachineState *machine)
                        0, FLASH_SIZE);
 }
 
-static void netduino2_machine_init(MachineClass *mc)
+static void netduino2_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
     static const char * const valid_cpu_types[] = {
         ARM_CPU_TYPE_NAME("cortex-m3"),
         NULL
@@ -65,4 +66,16 @@ static void netduino2_machine_init(MachineClass *mc)
     mc->ignore_memory_transaction_failures = true;
 }
 
-DEFINE_MACHINE("netduino2", netduino2_machine_init)
+static const TypeInfo netduino2_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("netduino2"),
+    .parent     = TYPE_MACHINE,
+    .class_init = netduino2_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void netduino2_machine_register_types(void)
+{
+    type_register_static(&netduino2_machine_typeinfo);
+}
+
+type_init(netduino2_machine_register_types)
diff --git a/hw/arm/netduinoplus2.c b/hw/arm/netduinoplus2.c
index 5ac0eb81637..169e7b80b3c 100644
--- a/hw/arm/netduinoplus2.c
+++ b/hw/arm/netduinoplus2.c
@@ -53,8 +53,9 @@ static void netduinoplus2_init(MachineState *machine)
                        0, FLASH_SIZE);
 }
 
-static void netduinoplus2_machine_init(MachineClass *mc)
+static void netduinoplus2_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
     static const char * const valid_cpu_types[] = {
         ARM_CPU_TYPE_NAME("cortex-m4"),
         NULL
@@ -65,4 +66,16 @@ static void netduinoplus2_machine_init(MachineClass *mc)
     mc->valid_cpu_types = valid_cpu_types;
 }
 
-DEFINE_MACHINE("netduinoplus2", netduinoplus2_machine_init)
+static const TypeInfo netduinoplus2_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("netduinoplus2"),
+    .parent     = TYPE_MACHINE,
+    .class_init = netduinoplus2_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void netduinoplus2_machine_register_types(void)
+{
+    type_register_static(&netduinoplus2_machine_typeinfo);
+}
+
+type_init(netduinoplus2_machine_register_types)
diff --git a/hw/arm/olimex-stm32-h405.c b/hw/arm/olimex-stm32-h405.c
index de9ac4978ce..4e415a420c4 100644
--- a/hw/arm/olimex-stm32-h405.c
+++ b/hw/arm/olimex-stm32-h405.c
@@ -56,8 +56,10 @@ static void olimex_stm32_h405_init(MachineState *machine)
                        0, FLASH_SIZE);
 }
 
-static void olimex_stm32_h405_machine_init(MachineClass *mc)
+static void olimex_stm32_h405_machine_class_init(ObjectClass *oc,
+                                                 const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
     static const char * const valid_cpu_types[] = {
         ARM_CPU_TYPE_NAME("cortex-m4"),
         NULL
@@ -71,4 +73,16 @@ static void olimex_stm32_h405_machine_init(MachineClass *mc)
     mc->default_ram_size = 0;
 }
 
-DEFINE_MACHINE("olimex-stm32-h405", olimex_stm32_h405_machine_init)
+static const TypeInfo olimex_stm32_h405_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("olimex-stm32-h405"),
+    .parent     = TYPE_MACHINE,
+    .class_init = olimex_stm32_h405_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void olimex_stm32_h405_machine_register_types(void)
+{
+    type_register_static(&olimex_stm32_h405_machine_typeinfo);
+}
+
+type_init(olimex_stm32_h405_machine_register_types)
diff --git a/hw/arm/orangepi.c b/hw/arm/orangepi.c
index 18ed174032b..ec1d19b6034 100644
--- a/hw/arm/orangepi.c
+++ b/hw/arm/orangepi.c
@@ -111,8 +111,9 @@ static void orangepi_init(MachineState *machine)
     arm_load_kernel(&h3->cpus[0], machine, &opms->bootinfo);
 }
 
-static void orangepi_machine_init(MachineClass *mc)
+static void orangepi_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
     static const char * const valid_cpu_types[] = {
         ARM_CPU_TYPE_NAME("cortex-a7"),
         NULL
@@ -132,6 +133,16 @@ static void orangepi_machine_init(MachineClass *mc)
     mc->auto_create_sdcard = true;
 }
 
-DEFINE_MACHINE_EXTENDED("orangepi-pc", MACHINE, OrangePiMachineState,
-                        orangepi_machine_init, false, false,
-                        NULL)
+static const TypeInfo orangepi_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("orangepi-pc"),
+    .parent     = TYPE_MACHINE,
+    .class_init = orangepi_machine_class_init,
+    .instance_size = sizeof(OrangePiMachineState),
+};
+
+static void orangepi_machine_register_types(void)
+{
+    type_register_static(&orangepi_machine_typeinfo);
+}
+
+type_init(orangepi_machine_register_types)
diff --git a/hw/arm/stm32vldiscovery.c b/hw/arm/stm32vldiscovery.c
index d899a134b38..ab9116ccc1d 100644
--- a/hw/arm/stm32vldiscovery.c
+++ b/hw/arm/stm32vldiscovery.c
@@ -56,8 +56,10 @@ static void stm32vldiscovery_init(MachineState *machine)
                        0, FLASH_SIZE);
 }
 
-static void stm32vldiscovery_machine_init(MachineClass *mc)
+static void stm32vldiscovery_machine_class_init(ObjectClass *oc,
+                                                const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
     static const char * const valid_cpu_types[] = {
         ARM_CPU_TYPE_NAME("cortex-m3"),
         NULL
@@ -68,4 +70,16 @@ static void stm32vldiscovery_machine_init(MachineClass *mc)
     mc->valid_cpu_types = valid_cpu_types;
 }
 
-DEFINE_MACHINE("stm32vldiscovery", stm32vldiscovery_machine_init)
+static const TypeInfo stm32vldiscovery_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("stm32vldiscovery"),
+    .parent     = TYPE_MACHINE,
+    .class_init = stm32vldiscovery_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void stm32vldiscovery_machine_register_types(void)
+{
+    type_register_static(&stm32vldiscovery_machine_typeinfo);
+}
+
+type_init(stm32vldiscovery_machine_register_types)
-- 
2.55.0.windows.3

[PATCH 06/15] hw/riscv: expand DEFINE_MACHINE for RISC-V machines

[Yonggang Luo]

Expand DEFINE_MACHINE() in hw/riscv/boston-aia.c and
hw/riscv/microblaze-v-generic.c to explicit TypeInfo and type_init()
functions calling type_register_static().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/riscv/boston-aia.c           | 18 ++++++++++++++++--
 hw/riscv/microblaze-v-generic.c | 18 ++++++++++++++++--
 2 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/hw/riscv/boston-aia.c b/hw/riscv/boston-aia.c
index b90da096ea8..54979eae86e 100644
--- a/hw/riscv/boston-aia.c
+++ b/hw/riscv/boston-aia.c
@@ -462,8 +462,10 @@ static void boston_mach_init(MachineState *machine)
     }
 }
 
-static void boston_mach_class_init(MachineClass *mc)
+static void boston_mach_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "MIPS Boston-aia";
     mc->init = boston_mach_init;
     mc->block_default_type = IF_IDE;
@@ -473,4 +475,16 @@ static void boston_mach_class_init(MachineClass *mc)
     mc->default_cpu_type = TYPE_RISCV_CPU_MIPS_P8700;
 }
 
-DEFINE_MACHINE("boston-aia", boston_mach_class_init)
+static const TypeInfo boston_mach_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("boston-aia"),
+    .parent     = TYPE_MACHINE,
+    .class_init = boston_mach_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void boston_mach_register_types(void)
+{
+    type_register_static(&boston_mach_typeinfo);
+}
+
+type_init(boston_mach_register_types)
diff --git a/hw/riscv/microblaze-v-generic.c b/hw/riscv/microblaze-v-generic.c
index b0494b1ac50..b0f837b6ee7 100644
--- a/hw/riscv/microblaze-v-generic.c
+++ b/hw/riscv/microblaze-v-generic.c
@@ -176,8 +176,10 @@ static void mb_v_generic_init(MachineState *machine)
     create_unimplemented_device("qspi", QSPI_BASEADDR, 0x10000);
 }
 
-static void mb_v_generic_machine_init(MachineClass *mc)
+static void mb_v_generic_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "AMD Microblaze-V generic platform";
     mc->init = mb_v_generic_init;
     mc->min_cpus = 1;
@@ -186,4 +188,16 @@ static void mb_v_generic_machine_init(MachineClass *mc)
     mc->default_cpus = 1;
 }
 
-DEFINE_MACHINE("amd-microblaze-v-generic", mb_v_generic_machine_init)
+static const TypeInfo mb_v_generic_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("amd-microblaze-v-generic"),
+    .parent     = TYPE_MACHINE,
+    .class_init = mb_v_generic_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void mb_v_generic_machine_register_types(void)
+{
+    type_register_static(&mb_v_generic_machine_typeinfo);
+}
+
+type_init(mb_v_generic_machine_register_types)
-- 
2.55.0.windows.3

[PATCH 07/15] hw/core/null-machine: expand DEFINE_MACHINE

[Yonggang Luo]

Expand DEFINE_MACHINE() for the none machine to
machine_none_machine_typeinfo and
machine_none_machine_register_types() calling type_register_static().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/core/null-machine.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/hw/core/null-machine.c b/hw/core/null-machine.c
index 60254913019..1f35b9169d1 100644
--- a/hw/core/null-machine.c
+++ b/hw/core/null-machine.c
@@ -42,8 +42,10 @@ static void machine_none_init(MachineState *mch)
     }
 }
 
-static void machine_none_machine_init(MachineClass *mc)
+static void machine_none_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "empty machine";
     mc->init = machine_none_init;
     mc->max_cpus = 1;
@@ -55,4 +57,16 @@ static void machine_none_machine_init(MachineClass *mc)
     mc->no_cdrom = 1;
 }
 
-DEFINE_MACHINE("none", machine_none_machine_init)
+static const TypeInfo machine_none_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("none"),
+    .parent     = TYPE_MACHINE,
+    .class_init = machine_none_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void machine_none_machine_register_types(void)
+{
+    type_register_static(&machine_none_machine_typeinfo);
+}
+
+type_init(machine_none_machine_register_types)
-- 
2.55.0.windows.3

[PATCH 08/15] hw/mips: expand DEFINE_MACHINE for MIPS machines

[Yonggang Luo]

Expand DEFINE_MACHINE() in hw/mips/boston.c, hw/mips/fuloong2e.c, and
hw/mips/malta.c to explicit TypeInfo and type_register_static() calls,
reusing mips_malta_register_types() in hw/mips/malta.c.

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/mips/boston.c    | 18 ++++++++++++++++--
 hw/mips/fuloong2e.c | 18 ++++++++++++++++--
 hw/mips/malta.c     | 12 ++++++++++--
 3 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/hw/mips/boston.c b/hw/mips/boston.c
index 4579df23eb7..2c6edebe257 100644
--- a/hw/mips/boston.c
+++ b/hw/mips/boston.c
@@ -839,8 +839,10 @@ static void boston_mach_init(MachineState *machine)
     }
 }
 
-static void boston_mach_class_init(MachineClass *mc)
+static void boston_mach_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "MIPS Boston";
     mc->init = boston_mach_init;
     mc->block_default_type = IF_IDE;
@@ -850,4 +852,16 @@ static void boston_mach_class_init(MachineClass *mc)
     mc->default_cpu_type = MIPS_CPU_TYPE_NAME("I6400");
 }
 
-DEFINE_MACHINE("boston", boston_mach_class_init)
+static const TypeInfo boston_mach_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("boston"),
+    .parent     = TYPE_MACHINE,
+    .class_init = boston_mach_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void boston_mach_register_types(void)
+{
+    type_register_static(&boston_mach_typeinfo);
+}
+
+type_init(boston_mach_register_types)
diff --git a/hw/mips/fuloong2e.c b/hw/mips/fuloong2e.c
index 9a712ee9309..96610ec1fdd 100644
--- a/hw/mips/fuloong2e.c
+++ b/hw/mips/fuloong2e.c
@@ -328,8 +328,10 @@ static void mips_fuloong2e_init(MachineState *machine)
     network_init(pci_bus);
 }
 
-static void mips_fuloong2e_machine_init(MachineClass *mc)
+static void mips_fuloong2e_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "Fuloong 2e mini pc";
     mc->init = mips_fuloong2e_init;
     mc->block_default_type = IF_IDE;
@@ -339,4 +341,16 @@ static void mips_fuloong2e_machine_init(MachineClass *mc)
     machine_add_audiodev_property(mc);
 }
 
-DEFINE_MACHINE("fuloong2e", mips_fuloong2e_machine_init)
+static const TypeInfo mips_fuloong2e_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("fuloong2e"),
+    .parent     = TYPE_MACHINE,
+    .class_init = mips_fuloong2e_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void mips_fuloong2e_machine_register_types(void)
+{
+    type_register_static(&mips_fuloong2e_machine_typeinfo);
+}
+
+type_init(mips_fuloong2e_machine_register_types)
diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index 38c71f66f2e..0a10a2fea13 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -1285,8 +1285,10 @@ GlobalProperty malta_compat[] = {
 };
 const size_t malta_compat_len = G_N_ELEMENTS(malta_compat);
 
-static void mips_malta_machine_init(MachineClass *mc)
+static void mips_malta_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "MIPS Malta Core LV";
     mc->init = mips_malta_init;
     mc->block_default_type = IF_IDE;
@@ -1301,11 +1303,17 @@ static void mips_malta_machine_init(MachineClass *mc)
     compat_props_add(mc->compat_props, malta_compat, malta_compat_len);
 }
 
-DEFINE_MACHINE("malta", mips_malta_machine_init)
+static const TypeInfo mips_malta_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("malta"),
+    .parent     = TYPE_MACHINE,
+    .class_init = mips_malta_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
 
 static void mips_malta_register_types(void)
 {
     type_register_static(&mips_malta_device);
+    type_register_static(&mips_malta_machine_typeinfo);
 }
 
 type_init(mips_malta_register_types)
-- 
2.55.0.windows.3

[PATCH 09/15] hw/ppc: expand DEFINE_MACHINE for PowerPC machines

[Yonggang Luo]

Expand DEFINE_MACHINE() and DEFINE_MACHINE_EXTENDED() in the PowerPC
machine files to explicit TypeInfo and type_register_static() calls,
adding the pegasos base machine to pegasos_machine_types[] in
hw/ppc/pegasos.c.

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/ppc/amigaone.c      | 18 ++++++++++++++++--
 hw/ppc/pegasos.c       | 21 ++++++++++++++-------
 hw/ppc/ppc440_bamboo.c | 18 ++++++++++++++++--
 hw/ppc/prep.c          | 18 ++++++++++++++++--
 hw/ppc/sam460ex.c      | 18 ++++++++++++++++--
 hw/ppc/virtex_ml507.c  | 18 ++++++++++++++++--
 6 files changed, 94 insertions(+), 17 deletions(-)

diff --git a/hw/ppc/amigaone.c b/hw/ppc/amigaone.c
index 2e94e80b569..3cd3e92d2d8 100644
--- a/hw/ppc/amigaone.c
+++ b/hw/ppc/amigaone.c
@@ -416,8 +416,10 @@ static void amigaone_init(MachineState *machine)
     }
 }
 
-static void amigaone_machine_init(MachineClass *mc)
+static void amigaone_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "Eyetech AmigaOne/Mai Logic Teron";
     mc->init = amigaone_init;
     mc->block_default_type = IF_IDE;
@@ -427,4 +429,16 @@ static void amigaone_machine_init(MachineClass *mc)
     mc->default_ram_size = 512 * MiB;
 }
 
-DEFINE_MACHINE("amigaone", amigaone_machine_init)
+static const TypeInfo amigaone_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("amigaone"),
+    .parent     = TYPE_MACHINE,
+    .class_init = amigaone_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void amigaone_machine_register_types(void)
+{
+    type_register_static(&amigaone_machine_typeinfo);
+}
+
+type_init(amigaone_machine_register_types)
diff --git a/hw/ppc/pegasos.c b/hw/ppc/pegasos.c
index fba2a558905..ffa63456320 100644
--- a/hw/ppc/pegasos.c
+++ b/hw/ppc/pegasos.c
@@ -732,8 +732,9 @@ static bool pegasos_setprop(MachineState *ms, const char *path,
     return true;
 }
 
-static void pegasos_machine_init(MachineClass *mc)
+static void pegasos_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
     PPCVirtualHypervisorClass *vhc = PPC_VIRTUAL_HYPERVISOR_CLASS(mc);
     VofMachineIfClass *vmc = VOF_MACHINE_CLASS(mc);
 
@@ -787,13 +788,19 @@ static void pegasos2_machine_class_init(ObjectClass *oc, const void *data)
     mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7457_v1.2");
 }
 
-DEFINE_MACHINE_EXTENDED("pegasos", MACHINE, PegasosMachineState,
-                        pegasos_machine_init, true, false,
-                        (const InterfaceInfo[]) {
-                        { TYPE_PPC_VIRTUAL_HYPERVISOR },
-                        { TYPE_VOF_MACHINE_IF }, { } })
-
 static const TypeInfo pegasos_machine_types[] = {
+    {
+        .name          = MACHINE_TYPE_NAME("pegasos"),
+        .parent        = TYPE_MACHINE,
+        .class_init    = pegasos_machine_class_init,
+        .instance_size = sizeof(PegasosMachineState),
+        .abstract      = true,
+        .interfaces    = (const InterfaceInfo[]) {
+            { TYPE_PPC_VIRTUAL_HYPERVISOR },
+            { TYPE_VOF_MACHINE_IF },
+            { }
+        },
+    },
     {
         .name          = MACHINE_TYPE_NAME("pegasos1"),
         .parent        = TYPE_PEGASOS_MACHINE,
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index 2dde008b0e4..401f7bee572 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -256,8 +256,10 @@ static void bamboo_init(MachineState *machine)
     }
 }
 
-static void bamboo_machine_init(MachineClass *mc)
+static void bamboo_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "bamboo";
     mc->init = bamboo_init;
     mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("440epb");
@@ -265,4 +267,16 @@ static void bamboo_machine_init(MachineClass *mc)
     mc->default_nic = "e1000";
 }
 
-DEFINE_MACHINE("bamboo", bamboo_machine_init)
+static const TypeInfo bamboo_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("bamboo"),
+    .parent     = TYPE_MACHINE,
+    .class_init = bamboo_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void bamboo_machine_register_types(void)
+{
+    type_register_static(&bamboo_machine_typeinfo);
+}
+
+type_init(bamboo_machine_register_types)
diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 2672eb9e7a7..4afc4e20c67 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -441,8 +441,10 @@ static void ibm_40p_init(MachineState *machine)
     }
 }
 
-static void ibm_40p_machine_init(MachineClass *mc)
+static void ibm_40p_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "IBM RS/6000 7020 (40p)",
     mc->init = ibm_40p_init;
     mc->max_cpus = 1;
@@ -456,4 +458,16 @@ static void ibm_40p_machine_init(MachineClass *mc)
     machine_add_audiodev_property(mc);
 }
 
-DEFINE_MACHINE("40p", ibm_40p_machine_init)
+static const TypeInfo ibm_40p_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("40p"),
+    .parent     = TYPE_MACHINE,
+    .class_init = ibm_40p_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void ibm_40p_machine_register_types(void)
+{
+    type_register_static(&ibm_40p_machine_typeinfo);
+}
+
+type_init(ibm_40p_machine_register_types)
diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
index b13dd224ba1..934ae3874c3 100644
--- a/hw/ppc/sam460ex.c
+++ b/hw/ppc/sam460ex.c
@@ -509,8 +509,10 @@ static void sam460ex_init(MachineState *machine)
     boot_info->entry = entry;
 }
 
-static void sam460ex_machine_init(MachineClass *mc)
+static void sam460ex_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "aCube Sam460ex";
     mc->init = sam460ex_init;
     mc->block_default_type = IF_IDE;
@@ -519,4 +521,16 @@ static void sam460ex_machine_init(MachineClass *mc)
     mc->default_ram_id = "ppc4xx.sdram";
 }
 
-DEFINE_MACHINE("sam460ex", sam460ex_machine_init)
+static const TypeInfo sam460ex_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("sam460ex"),
+    .parent     = TYPE_MACHINE,
+    .class_init = sam460ex_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void sam460ex_machine_register_types(void)
+{
+    type_register_static(&sam460ex_machine_typeinfo);
+}
+
+type_init(sam460ex_machine_register_types)
diff --git a/hw/ppc/virtex_ml507.c b/hw/ppc/virtex_ml507.c
index 09686360e16..2a4c8c9fc93 100644
--- a/hw/ppc/virtex_ml507.c
+++ b/hw/ppc/virtex_ml507.c
@@ -281,12 +281,26 @@ static void virtex_init(MachineState *machine)
     env->load_info = &boot_info;
 }
 
-static void virtex_machine_init(MachineClass *mc)
+static void virtex_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "Xilinx Virtex ML507 reference design";
     mc->init = virtex_init;
     mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("440-xilinx");
     mc->default_ram_id = "ram";
 }
 
-DEFINE_MACHINE("virtex-ml507", virtex_machine_init)
+static const TypeInfo virtex_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("virtex-ml507"),
+    .parent     = TYPE_MACHINE,
+    .class_init = virtex_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void virtex_machine_register_types(void)
+{
+    type_register_static(&virtex_machine_typeinfo);
+}
+
+type_init(virtex_machine_register_types)
-- 
2.55.0.windows.3

[PATCH 10/15] hw/sh4: expand DEFINE_MACHINE in r2d.c

[Yonggang Luo]

Expand DEFINE_MACHINE() in hw/sh4/r2d.c to r2d_machine_typeinfo and
r2d_machine_register_types() calling type_register_static().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/sh4/r2d.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/hw/sh4/r2d.c b/hw/sh4/r2d.c
index 99afe3618e8..fb80c935ea6 100644
--- a/hw/sh4/r2d.c
+++ b/hw/sh4/r2d.c
@@ -378,8 +378,10 @@ static void r2d_init(MachineState *machine)
                        SDRAM_BASE + BOOT_PARAMS_OFFSET);
 }
 
-static void r2d_machine_init(MachineClass *mc)
+static void r2d_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "r2d-plus board";
     mc->init = r2d_init;
     mc->block_default_type = IF_IDE;
@@ -387,4 +389,16 @@ static void r2d_machine_init(MachineClass *mc)
     mc->default_nic = "rtl8139";
 }
 
-DEFINE_MACHINE("r2d", r2d_machine_init)
+static const TypeInfo r2d_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("r2d"),
+    .parent     = TYPE_MACHINE,
+    .class_init = r2d_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void r2d_machine_register_types(void)
+{
+    type_register_static(&r2d_machine_typeinfo);
+}
+
+type_init(r2d_machine_register_types)
-- 
2.55.0.windows.3

[PATCH 11/15] hw/sparc: expand DEFINE_MACHINE in leon3.c

[Yonggang Luo]

Expand DEFINE_MACHINE() in hw/sparc/leon3.c to
leon3_generic_machine_typeinfo and leon3_generic_machine_register_types()
calling type_register_static().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/sparc/leon3.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/hw/sparc/leon3.c b/hw/sparc/leon3.c
index d4a6e917598..ddc25f528ff 100644
--- a/hw/sparc/leon3.c
+++ b/hw/sparc/leon3.c
@@ -434,8 +434,10 @@ static void leon3_generic_hw_init(MachineState *machine)
                             LEON3_UART_IRQ, GRLIB_APBIO_AREA);
 }
 
-static void leon3_generic_machine_init(MachineClass *mc)
+static void leon3_generic_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "Leon-3 generic";
     mc->init = leon3_generic_hw_init;
     mc->default_cpu_type = SPARC_CPU_TYPE_NAME("LEON3");
@@ -443,4 +445,16 @@ static void leon3_generic_machine_init(MachineClass *mc)
     mc->max_cpus = MAX_CPUS;
 }
 
-DEFINE_MACHINE("leon3_generic", leon3_generic_machine_init)
+static const TypeInfo leon3_generic_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("leon3_generic"),
+    .parent     = TYPE_MACHINE,
+    .class_init = leon3_generic_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void leon3_generic_machine_register_types(void)
+{
+    type_register_static(&leon3_generic_machine_typeinfo);
+}
+
+type_init(leon3_generic_machine_register_types)
-- 
2.55.0.windows.3

[PATCH 12/15] hw/xenpv: expand DEFINE_MACHINE in xen_machine_pv.c

[Yonggang Luo]

Expand DEFINE_MACHINE() in hw/xenpv/xen_machine_pv.c to
xenpv_machine_typeinfo and xenpv_machine_register_types() calling
type_register_static().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/xenpv/xen_machine_pv.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
index c406821c34c..85ba65a3243 100644
--- a/hw/xenpv/xen_machine_pv.c
+++ b/hw/xenpv/xen_machine_pv.c
@@ -61,12 +61,26 @@ static void xen_init_pv(MachineState *machine)
     atexit(xen_config_cleanup);
 }
 
-static void xenpv_machine_init(MachineClass *mc)
+static void xenpv_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "Xen Para-virtualized PC";
     mc->init = xen_init_pv;
     mc->max_cpus = 1;
     mc->default_machine_opts = "accel=xen";
 }
 
-DEFINE_MACHINE("xenpv", xenpv_machine_init)
+static const TypeInfo xenpv_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("xenpv"),
+    .parent     = TYPE_MACHINE,
+    .class_init = xenpv_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void xenpv_machine_register_types(void)
+{
+    type_register_static(&xenpv_machine_typeinfo);
+}
+
+type_init(xenpv_machine_register_types)
-- 
2.55.0.windows.3

[PATCH 13/15] hw/xtensa: expand DEFINE_MACHINE in sim.c

[Yonggang Luo]

Expand DEFINE_MACHINE() in hw/xtensa/sim.c to xtensa_sim_machine_typeinfo
and xtensa_sim_machine_register_types() calling type_register_static().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/xtensa/sim.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/hw/xtensa/sim.c b/hw/xtensa/sim.c
index 835cd04fe01..fd66009b950 100644
--- a/hw/xtensa/sim.c
+++ b/hw/xtensa/sim.c
@@ -121,8 +121,10 @@ static void xtensa_sim_init(MachineState *machine)
     xtensa_sim_load_kernel(cpu, machine);
 }
 
-static void xtensa_sim_machine_init(MachineClass *mc)
+static void xtensa_sim_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "sim machine (" XTENSA_DEFAULT_CPU_MODEL ")";
     mc->is_default = true;
     mc->init = xtensa_sim_init;
@@ -131,4 +133,16 @@ static void xtensa_sim_machine_init(MachineClass *mc)
     mc->default_cpu_type = XTENSA_DEFAULT_CPU_TYPE;
 }
 
-DEFINE_MACHINE("sim", xtensa_sim_machine_init)
+static const TypeInfo xtensa_sim_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("sim"),
+    .parent     = TYPE_MACHINE,
+    .class_init = xtensa_sim_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void xtensa_sim_machine_register_types(void)
+{
+    type_register_static(&xtensa_sim_machine_typeinfo);
+}
+
+type_init(xtensa_sim_machine_register_types)
-- 
2.55.0.windows.3

[PATCH 14/15] hw/xtensa: expand DEFINE_MACHINE in virt.c

[Yonggang Luo]

Expand DEFINE_MACHINE() in hw/xtensa/virt.c to xtensa_virt_machine_typeinfo
and xtensa_virt_machine_register_types() calling type_register_static().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/xtensa/virt.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/hw/xtensa/virt.c b/hw/xtensa/virt.c
index 271f06e0953..8c8fdad72f0 100644
--- a/hw/xtensa/virt.c
+++ b/hw/xtensa/virt.c
@@ -115,8 +115,10 @@ static void xtensa_virt_init(MachineState *machine)
     xtensa_sim_load_kernel(cpu, machine);
 }
 
-static void xtensa_virt_machine_init(MachineClass *mc)
+static void xtensa_virt_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "virt machine (" XTENSA_DEFAULT_CPU_MODEL ")";
     mc->init = xtensa_virt_init;
     mc->max_cpus = 32;
@@ -124,4 +126,16 @@ static void xtensa_virt_machine_init(MachineClass *mc)
     mc->default_nic = "virtio-net-pci";
 }
 
-DEFINE_MACHINE("virt", xtensa_virt_machine_init)
+static const TypeInfo xtensa_virt_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("virt"),
+    .parent     = TYPE_MACHINE,
+    .class_init = xtensa_virt_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void xtensa_virt_machine_register_types(void)
+{
+    type_register_static(&xtensa_virt_machine_typeinfo);
+}
+
+type_init(xtensa_virt_machine_register_types)
-- 
2.55.0.windows.3

[PATCH 15/15] hw/core/boards: remove unused DEFINE_MACHINE* macros

[Yonggang Luo]

All DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED callers have been
expanded to explicit TypeInfo definitions, leaving DEFINE_MACHINE* and
DEFINE_SECURE_MACHINE* in include/hw/core/boards.h unused. Remove them.

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 include/hw/core/boards.h | 48 ----------------------------------------
 1 file changed, 48 deletions(-)

diff --git a/include/hw/core/boards.h b/include/hw/core/boards.h
index d0e4ad98201..8af927e9b7c 100644
--- a/include/hw/core/boards.h
+++ b/include/hw/core/boards.h
@@ -513,54 +513,6 @@ struct MachineState {
  *      DEFINE_VIRT_MACHINE_IMPL(false, major, minor, micro, _, tag)
  */
 
-#define DEFINE_MACHINE_EXTENDED(namestr, PARENT_NAME, InstanceName, \
-                                machine_initfn, ABSTRACT, SECURE, ifaces...) \
-    static void machine_initfn##_class_init(ObjectClass *oc, const void *data) \
-    { \
-        MachineClass *mc = MACHINE_CLASS(oc); \
-        machine_initfn(mc); \
-    } \
-    static const TypeInfo machine_initfn##_typeinfo = { \
-        .name       = MACHINE_TYPE_NAME(namestr), \
-        .parent     = TYPE_##PARENT_NAME, \
-        .class_init = machine_initfn##_class_init, \
-        .instance_size = sizeof(InstanceName), \
-        .abstract = ABSTRACT, \
-        .secure     = SECURE, \
-        .interfaces = ifaces, \
-    }; \
-    static void machine_initfn##_register_types(void) \
-    { \
-        type_register_static(&machine_initfn##_typeinfo); \
-    } \
-    type_init(machine_initfn##_register_types)
-
-/* Implicitly insecure */
-#define DEFINE_MACHINE(namestr, machine_initfn) \
-    DEFINE_MACHINE_EXTENDED(namestr, MACHINE, MachineState, machine_initfn, \
-                            false, false, NULL)
-
-#define DEFINE_MACHINE_WITH_INTERFACE_ARRAY(namestr, machine_initfn, ifaces...) \
-    DEFINE_MACHINE_EXTENDED(namestr, MACHINE, MachineState, machine_initfn, \
-                            false, false, ifaces)
-
-#define DEFINE_MACHINE_WITH_INTERFACES(namestr, machine_initfn, ...)    \
-    DEFINE_MACHINE_WITH_INTERFACE_ARRAY(namestr, machine_initfn, \
-                                        (const InterfaceInfo[]) { __VA_ARGS__ })
-
-
-#define DEFINE_SECURE_MACHINE(namestr, machine_initfn) \
-    DEFINE_MACHINE_EXTENDED(namestr, MACHINE, MachineState, machine_initfn, \
-                            false, true, NULL)
-
-#define DEFINE_SECURE_MACHINE_WITH_INTERFACE_ARRAY(namestr, machine_initfn, ifaces...) \
-    DEFINE_MACHINE_EXTENDED(namestr, MACHINE, MachineState, machine_initfn, \
-                            false, true, ifaces)
-
-#define DEFINE_SECURE_MACHINE_WITH_INTERFACES(namestr, machine_initfn, ...) \
-    DEFINE_SECURE_MACHINE_WITH_INTERFACE_ARRAY(namestr, machine_initfn, \
-                                               (const InterfaceInfo[]) { __VA_ARGS__ })
-
 /*
  * Helper for dispatching different macros based on how
  * many __VA_ARGS__ are passed. Supports 1 to 5 variadic
-- 
2.55.0.windows.3

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Pierrick Bouvier]

On 10/30/2026 7:15 AM, Yonggang Luo wrote:
> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the type_init
> function that calls type_register_static(). A later change needs to pass a
> target mask into that registration, and the macros have no parameter for it.
> This series expands every caller first, with no behavior change, so the
> follow-up only replaces the type_register_static() call.
> 
> Each machine file gains a class_init function, a TypeInfo, and a type_init
> function that calls type_register_static(). The last patch removes
> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
> 
> Yonggang Luo (15):
>   hw/alpha: expand DEFINE_MACHINE in dp264.c
>   hw/m68k: expand DEFINE_MACHINE for M68K machines
>   hw/microblaze: expand DEFINE_MACHINE for MicroBlaze
>   hw/tricore: expand DEFINE_MACHINE in tricore_testboard.c
>   hw/arm: expand DEFINE_MACHINE for ARM machines
>   hw/riscv: expand DEFINE_MACHINE for RISC-V machines
>   hw/core/null-machine: expand DEFINE_MACHINE
>   hw/mips: expand DEFINE_MACHINE for MIPS machines
>   hw/ppc: expand DEFINE_MACHINE for PowerPC machines
>   hw/sh4: expand DEFINE_MACHINE in r2d.c
>   hw/sparc: expand DEFINE_MACHINE in leon3.c
>   hw/xenpv: expand DEFINE_MACHINE in xen_machine_pv.c
>   hw/xtensa: expand DEFINE_MACHINE in sim.c
>   hw/xtensa: expand DEFINE_MACHINE in virt.c
>   hw/core/boards: remove unused DEFINE_MACHINE* macros
> 
>  hw/alpha/dp264.c                    | 18 +++++++++--
>  hw/arm/bananapi_m2u.c               | 18 +++++++++--
>  hw/arm/cubieboard.c                 | 19 +++++++++---
>  hw/arm/digic_boards.c               | 18 +++++++++--
>  hw/arm/imx25_pdk.c                  | 18 +++++++++--
>  hw/arm/imx8mm-evk.c                 | 20 +++++++++---
>  hw/arm/integratorcp.c               | 14 ++++++---
>  hw/arm/kzm.c                        | 18 +++++++++--
>  hw/arm/max78000fthr.c               | 17 ++++++++--
>  hw/arm/mcimx6ul-evk.c               | 18 +++++++++--
>  hw/arm/mcimx7d-sabre.c              | 20 +++++++++---
>  hw/arm/msf2-som.c                   | 17 ++++++++--
>  hw/arm/netduino2.c                  | 17 ++++++++--
>  hw/arm/netduinoplus2.c              | 17 ++++++++--
>  hw/arm/olimex-stm32-h405.c          | 18 +++++++++--
>  hw/arm/orangepi.c                   | 19 +++++++++---
>  hw/arm/stm32vldiscovery.c           | 18 +++++++++--
>  hw/core/null-machine.c              | 18 +++++++++--
>  hw/m68k/an5206.c                    | 18 +++++++++--
>  hw/m68k/mcf5208.c                   | 18 +++++++++--
>  hw/microblaze/petalogix_ml605_mmu.c | 19 ++++++++++--
>  hw/microblaze/xlnx-zynqmp-pmu.c     | 19 ++++++++++--
>  hw/mips/boston.c                    | 18 +++++++++--
>  hw/mips/fuloong2e.c                 | 18 +++++++++--
>  hw/mips/malta.c                     | 12 ++++++--
>  hw/ppc/amigaone.c                   | 18 +++++++++--
>  hw/ppc/pegasos.c                    | 21 ++++++++-----
>  hw/ppc/ppc440_bamboo.c              | 18 +++++++++--
>  hw/ppc/prep.c                       | 18 +++++++++--
>  hw/ppc/sam460ex.c                   | 18 +++++++++--
>  hw/ppc/virtex_ml507.c               | 18 +++++++++--
>  hw/riscv/boston-aia.c               | 18 +++++++++--
>  hw/riscv/microblaze-v-generic.c     | 18 +++++++++--
>  hw/sh4/r2d.c                        | 18 +++++++++--
>  hw/sparc/leon3.c                    | 18 +++++++++--
>  hw/tricore/tricore_testboard.c      | 18 +++++++++--
>  hw/xenpv/xen_machine_pv.c           | 18 +++++++++--
>  hw/xtensa/sim.c                     | 18 +++++++++--
>  hw/xtensa/virt.c                    | 18 +++++++++--
>  include/hw/core/boards.h            | 48 -----------------------------
>  40 files changed, 605 insertions(+), 142 deletions(-)
> 

So far, this expansion has been done only on machines that required to
modify TypeInfo: mostly virt types, which are ambiguous between targets
and require to introduce is_available.

Maybe this can be delayed for when such machines require it also.

Regards,
Pierrick

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[BALATON Zoltan]

On Fri, 30 Oct 2026, Yonggang Luo wrote:
> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the type_init
> function that calls type_register_static(). A later change needs to pass a

That's the point of the macro to hide the boiler plate code.

> target mask into that registration, and the macros have no parameter for it.

Couldn't you just change the macros to take that parameter instead of 
expanding it everywhere?

Regards,
BALATON Zoltan

> This series expands every caller first, with no behavior change, so the
> follow-up only replaces the type_register_static() call.
>
> Each machine file gains a class_init function, a TypeInfo, and a type_init
> function that calls type_register_static(). The last patch removes
> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
>
> Yonggang Luo (15):
>  hw/alpha: expand DEFINE_MACHINE in dp264.c
>  hw/m68k: expand DEFINE_MACHINE for M68K machines
>  hw/microblaze: expand DEFINE_MACHINE for MicroBlaze
>  hw/tricore: expand DEFINE_MACHINE in tricore_testboard.c
>  hw/arm: expand DEFINE_MACHINE for ARM machines
>  hw/riscv: expand DEFINE_MACHINE for RISC-V machines
>  hw/core/null-machine: expand DEFINE_MACHINE
>  hw/mips: expand DEFINE_MACHINE for MIPS machines
>  hw/ppc: expand DEFINE_MACHINE for PowerPC machines
>  hw/sh4: expand DEFINE_MACHINE in r2d.c
>  hw/sparc: expand DEFINE_MACHINE in leon3.c
>  hw/xenpv: expand DEFINE_MACHINE in xen_machine_pv.c
>  hw/xtensa: expand DEFINE_MACHINE in sim.c
>  hw/xtensa: expand DEFINE_MACHINE in virt.c
>  hw/core/boards: remove unused DEFINE_MACHINE* macros
>
> hw/alpha/dp264.c                    | 18 +++++++++--
> hw/arm/bananapi_m2u.c               | 18 +++++++++--
> hw/arm/cubieboard.c                 | 19 +++++++++---
> hw/arm/digic_boards.c               | 18 +++++++++--
> hw/arm/imx25_pdk.c                  | 18 +++++++++--
> hw/arm/imx8mm-evk.c                 | 20 +++++++++---
> hw/arm/integratorcp.c               | 14 ++++++---
> hw/arm/kzm.c                        | 18 +++++++++--
> hw/arm/max78000fthr.c               | 17 ++++++++--
> hw/arm/mcimx6ul-evk.c               | 18 +++++++++--
> hw/arm/mcimx7d-sabre.c              | 20 +++++++++---
> hw/arm/msf2-som.c                   | 17 ++++++++--
> hw/arm/netduino2.c                  | 17 ++++++++--
> hw/arm/netduinoplus2.c              | 17 ++++++++--
> hw/arm/olimex-stm32-h405.c          | 18 +++++++++--
> hw/arm/orangepi.c                   | 19 +++++++++---
> hw/arm/stm32vldiscovery.c           | 18 +++++++++--
> hw/core/null-machine.c              | 18 +++++++++--
> hw/m68k/an5206.c                    | 18 +++++++++--
> hw/m68k/mcf5208.c                   | 18 +++++++++--
> hw/microblaze/petalogix_ml605_mmu.c | 19 ++++++++++--
> hw/microblaze/xlnx-zynqmp-pmu.c     | 19 ++++++++++--
> hw/mips/boston.c                    | 18 +++++++++--
> hw/mips/fuloong2e.c                 | 18 +++++++++--
> hw/mips/malta.c                     | 12 ++++++--
> hw/ppc/amigaone.c                   | 18 +++++++++--
> hw/ppc/pegasos.c                    | 21 ++++++++-----
> hw/ppc/ppc440_bamboo.c              | 18 +++++++++--
> hw/ppc/prep.c                       | 18 +++++++++--
> hw/ppc/sam460ex.c                   | 18 +++++++++--
> hw/ppc/virtex_ml507.c               | 18 +++++++++--
> hw/riscv/boston-aia.c               | 18 +++++++++--
> hw/riscv/microblaze-v-generic.c     | 18 +++++++++--
> hw/sh4/r2d.c                        | 18 +++++++++--
> hw/sparc/leon3.c                    | 18 +++++++++--
> hw/tricore/tricore_testboard.c      | 18 +++++++++--
> hw/xenpv/xen_machine_pv.c           | 18 +++++++++--
> hw/xtensa/sim.c                     | 18 +++++++++--
> hw/xtensa/virt.c                    | 18 +++++++++--
> include/hw/core/boards.h            | 48 -----------------------------
> 40 files changed, 605 insertions(+), 142 deletions(-)
>
>

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Pierrick Bouvier]

On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> On Fri, 30 Oct 2026, Yonggang Luo wrote:
>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
>> type_init
>> function that calls type_register_static(). A later change needs to
>> pass a
> 
> That's the point of the macro to hide the boiler plate code.
> 
>> target mask into that registration, and the macros have no parameter
>> for it.
> 
> Couldn't you just change the macros to take that parameter instead of
> expanding it everywhere?
>

Problem of macros is that they don't have default parameters, so you
need variants for everything:

DEFINE_MACHINE
DEFINE_MACHINE_EXTENDED
DEFINE_MACHINE_WITH_INTERFACES
DEFINE_MACHINE_WITH_INTERFACE_ARRAY
and now would need a new variant, with variant for other existing ones.

In the end, it's just simpler to remove this and add the boilerplate.
It's written once and never modified, so using a macro just save typing
those lines once.

> Regards,
> BALATON Zoltan
> 
>> This series expands every caller first, with no behavior change, so the
>> follow-up only replaces the type_register_static() call.
>>
>> Each machine file gains a class_init function, a TypeInfo, and a
>> type_init
>> function that calls type_register_static(). The last patch removes
>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
>>
>> Yonggang Luo (15):
>>  hw/alpha: expand DEFINE_MACHINE in dp264.c
>>  hw/m68k: expand DEFINE_MACHINE for M68K machines
>>  hw/microblaze: expand DEFINE_MACHINE for MicroBlaze
>>  hw/tricore: expand DEFINE_MACHINE in tricore_testboard.c
>>  hw/arm: expand DEFINE_MACHINE for ARM machines
>>  hw/riscv: expand DEFINE_MACHINE for RISC-V machines
>>  hw/core/null-machine: expand DEFINE_MACHINE
>>  hw/mips: expand DEFINE_MACHINE for MIPS machines
>>  hw/ppc: expand DEFINE_MACHINE for PowerPC machines
>>  hw/sh4: expand DEFINE_MACHINE in r2d.c
>>  hw/sparc: expand DEFINE_MACHINE in leon3.c
>>  hw/xenpv: expand DEFINE_MACHINE in xen_machine_pv.c
>>  hw/xtensa: expand DEFINE_MACHINE in sim.c
>>  hw/xtensa: expand DEFINE_MACHINE in virt.c
>>  hw/core/boards: remove unused DEFINE_MACHINE* macros
>>
>> hw/alpha/dp264.c                    | 18 +++++++++--
>> hw/arm/bananapi_m2u.c               | 18 +++++++++--
>> hw/arm/cubieboard.c                 | 19 +++++++++---
>> hw/arm/digic_boards.c               | 18 +++++++++--
>> hw/arm/imx25_pdk.c                  | 18 +++++++++--
>> hw/arm/imx8mm-evk.c                 | 20 +++++++++---
>> hw/arm/integratorcp.c               | 14 ++++++---
>> hw/arm/kzm.c                        | 18 +++++++++--
>> hw/arm/max78000fthr.c               | 17 ++++++++--
>> hw/arm/mcimx6ul-evk.c               | 18 +++++++++--
>> hw/arm/mcimx7d-sabre.c              | 20 +++++++++---
>> hw/arm/msf2-som.c                   | 17 ++++++++--
>> hw/arm/netduino2.c                  | 17 ++++++++--
>> hw/arm/netduinoplus2.c              | 17 ++++++++--
>> hw/arm/olimex-stm32-h405.c          | 18 +++++++++--
>> hw/arm/orangepi.c                   | 19 +++++++++---
>> hw/arm/stm32vldiscovery.c           | 18 +++++++++--
>> hw/core/null-machine.c              | 18 +++++++++--
>> hw/m68k/an5206.c                    | 18 +++++++++--
>> hw/m68k/mcf5208.c                   | 18 +++++++++--
>> hw/microblaze/petalogix_ml605_mmu.c | 19 ++++++++++--
>> hw/microblaze/xlnx-zynqmp-pmu.c     | 19 ++++++++++--
>> hw/mips/boston.c                    | 18 +++++++++--
>> hw/mips/fuloong2e.c                 | 18 +++++++++--
>> hw/mips/malta.c                     | 12 ++++++--
>> hw/ppc/amigaone.c                   | 18 +++++++++--
>> hw/ppc/pegasos.c                    | 21 ++++++++-----
>> hw/ppc/ppc440_bamboo.c              | 18 +++++++++--
>> hw/ppc/prep.c                       | 18 +++++++++--
>> hw/ppc/sam460ex.c                   | 18 +++++++++--
>> hw/ppc/virtex_ml507.c               | 18 +++++++++--
>> hw/riscv/boston-aia.c               | 18 +++++++++--
>> hw/riscv/microblaze-v-generic.c     | 18 +++++++++--
>> hw/sh4/r2d.c                        | 18 +++++++++--
>> hw/sparc/leon3.c                    | 18 +++++++++--
>> hw/tricore/tricore_testboard.c      | 18 +++++++++--
>> hw/xenpv/xen_machine_pv.c           | 18 +++++++++--
>> hw/xtensa/sim.c                     | 18 +++++++++--
>> hw/xtensa/virt.c                    | 18 +++++++++--
>> include/hw/core/boards.h            | 48 -----------------------------
>> 40 files changed, 605 insertions(+), 142 deletions(-)
>>
>>

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

On Sat, Oct 31, 2026 at 9:51 AM Pierrick Bouvier
<pierrick.bouvier@oss.qualcomm.com> wrote:
>
> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> > On Fri, 30 Oct 2026, Yonggang Luo wrote:
> >> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
> >> type_init
> >> function that calls type_register_static(). A later change needs to
> >> pass a
> >
> > That's the point of the macro to hide the boiler plate code.
> >
> >> target mask into that registration, and the macros have no parameter
> >> for it.
> >
> > Couldn't you just change the macros to take that parameter instead of
> > expanding it everywhere?
> >
>
> Problem of macros is that they don't have default parameters, so you
> need variants for everything:
>
> DEFINE_MACHINE
> DEFINE_MACHINE_EXTENDED
> DEFINE_MACHINE_WITH_INTERFACES
> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> and now would need a new variant, with variant for other existing ones.
>
> In the end, it's just simpler to remove this and add the boilerplate.
> It's written once and never modified, so using a macro just save typing
> those lines once.

Yeap, as now I have a working TypeImpl::targets and TypeBucket locally, that
looks minimal, so I am moving forward. This series is reject, then let
us delay the EXPAND
of DEFINE_MACHINE_* macros work later.

>
> > Regards,
> > BALATON Zoltan
> >
> >> This series expands every caller first, with no behavior change, so the
> >> follow-up only replaces the type_register_static() call.
> >>
> >> Each machine file gains a class_init function, a TypeInfo, and a
> >> type_init
> >> function that calls type_register_static(). The last patch removes
> >> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
> >>
> >> Yonggang Luo (15):
> >>  hw/alpha: expand DEFINE_MACHINE in dp264.c
> >>  hw/m68k: expand DEFINE_MACHINE for M68K machines
> >>  hw/microblaze: expand DEFINE_MACHINE for MicroBlaze
> >>  hw/tricore: expand DEFINE_MACHINE in tricore_testboard.c
> >>  hw/arm: expand DEFINE_MACHINE for ARM machines
> >>  hw/riscv: expand DEFINE_MACHINE for RISC-V machines
> >>  hw/core/null-machine: expand DEFINE_MACHINE
> >>  hw/mips: expand DEFINE_MACHINE for MIPS machines
> >>  hw/ppc: expand DEFINE_MACHINE for PowerPC machines
> >>  hw/sh4: expand DEFINE_MACHINE in r2d.c
> >>  hw/sparc: expand DEFINE_MACHINE in leon3.c
> >>  hw/xenpv: expand DEFINE_MACHINE in xen_machine_pv.c
> >>  hw/xtensa: expand DEFINE_MACHINE in sim.c
> >>  hw/xtensa: expand DEFINE_MACHINE in virt.c
> >>  hw/core/boards: remove unused DEFINE_MACHINE* macros
> >>
> >> hw/alpha/dp264.c                    | 18 +++++++++--
> >> hw/arm/bananapi_m2u.c               | 18 +++++++++--
> >> hw/arm/cubieboard.c                 | 19 +++++++++---
> >> hw/arm/digic_boards.c               | 18 +++++++++--
> >> hw/arm/imx25_pdk.c                  | 18 +++++++++--
> >> hw/arm/imx8mm-evk.c                 | 20 +++++++++---
> >> hw/arm/integratorcp.c               | 14 ++++++---
> >> hw/arm/kzm.c                        | 18 +++++++++--
> >> hw/arm/max78000fthr.c               | 17 ++++++++--
> >> hw/arm/mcimx6ul-evk.c               | 18 +++++++++--
> >> hw/arm/mcimx7d-sabre.c              | 20 +++++++++---
> >> hw/arm/msf2-som.c                   | 17 ++++++++--
> >> hw/arm/netduino2.c                  | 17 ++++++++--
> >> hw/arm/netduinoplus2.c              | 17 ++++++++--
> >> hw/arm/olimex-stm32-h405.c          | 18 +++++++++--
> >> hw/arm/orangepi.c                   | 19 +++++++++---
> >> hw/arm/stm32vldiscovery.c           | 18 +++++++++--
> >> hw/core/null-machine.c              | 18 +++++++++--
> >> hw/m68k/an5206.c                    | 18 +++++++++--
> >> hw/m68k/mcf5208.c                   | 18 +++++++++--
> >> hw/microblaze/petalogix_ml605_mmu.c | 19 ++++++++++--
> >> hw/microblaze/xlnx-zynqmp-pmu.c     | 19 ++++++++++--
> >> hw/mips/boston.c                    | 18 +++++++++--
> >> hw/mips/fuloong2e.c                 | 18 +++++++++--
> >> hw/mips/malta.c                     | 12 ++++++--
> >> hw/ppc/amigaone.c                   | 18 +++++++++--
> >> hw/ppc/pegasos.c                    | 21 ++++++++-----
> >> hw/ppc/ppc440_bamboo.c              | 18 +++++++++--
> >> hw/ppc/prep.c                       | 18 +++++++++--
> >> hw/ppc/sam460ex.c                   | 18 +++++++++--
> >> hw/ppc/virtex_ml507.c               | 18 +++++++++--
> >> hw/riscv/boston-aia.c               | 18 +++++++++--
> >> hw/riscv/microblaze-v-generic.c     | 18 +++++++++--
> >> hw/sh4/r2d.c                        | 18 +++++++++--
> >> hw/sparc/leon3.c                    | 18 +++++++++--
> >> hw/tricore/tricore_testboard.c      | 18 +++++++++--
> >> hw/xenpv/xen_machine_pv.c           | 18 +++++++++--
> >> hw/xtensa/sim.c                     | 18 +++++++++--
> >> hw/xtensa/virt.c                    | 18 +++++++++--
> >> include/hw/core/boards.h            | 48 -----------------------------
> >> 40 files changed, 605 insertions(+), 142 deletions(-)
> >>
> >>
>


-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[BALATON Zoltan]

On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
>>> type_init
>>> function that calls type_register_static(). A later change needs to
>>> pass a
>>
>> That's the point of the macro to hide the boiler plate code.
>>
>>> target mask into that registration, and the macros have no parameter
>>> for it.
>>
>> Couldn't you just change the macros to take that parameter instead of
>> expanding it everywhere?
>>
>
> Problem of macros is that they don't have default parameters, so you
> need variants for everything:
>
> DEFINE_MACHINE
> DEFINE_MACHINE_EXTENDED
> DEFINE_MACHINE_WITH_INTERFACES
> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> and now would need a new variant, with variant for other existing ones.
>
> In the end, it's just simpler to remove this and add the boilerplate.
> It's written once and never modified, so using a macro just save typing
> those lines once.
>
>> Regards,
>> BALATON Zoltan
>>
>>> This series expands every caller first, with no behavior change, so the
>>> follow-up only replaces the type_register_static() call.
>>>
>>> Each machine file gains a class_init function, a TypeInfo, and a
>>> type_init
>>> function that calls type_register_static(). The last patch removes
>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.

Macros help reading the code not saving typing. If the actual 
functionality is buried in a lot of boiler plate it's harder to understand 
and spot bugs so putting the unintresting boiler plate behind a macro is 
better even if you need a separate version for different cases. Then the 
code that uses the macro will be much more obvious and not just a lot of 
boiler plate.

Regards,
BALATON Zoltan

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
> > On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> >> On Fri, 30 Oct 2026, Yonggang Luo wrote:
> >>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
> >>> type_init
> >>> function that calls type_register_static(). A later change needs to
> >>> pass a
> >>
> >> That's the point of the macro to hide the boiler plate code.
> >>
> >>> target mask into that registration, and the macros have no parameter
> >>> for it.
> >>
> >> Couldn't you just change the macros to take that parameter instead of
> >> expanding it everywhere?
> >>
> >
> > Problem of macros is that they don't have default parameters, so you
> > need variants for everything:
> >
> > DEFINE_MACHINE
> > DEFINE_MACHINE_EXTENDED
> > DEFINE_MACHINE_WITH_INTERFACES
> > DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> > and now would need a new variant, with variant for other existing ones.
> >
> > In the end, it's just simpler to remove this and add the boilerplate.
> > It's written once and never modified, so using a macro just save typing
> > those lines once.
> >
> >> Regards,
> >> BALATON Zoltan
> >>
> >>> This series expands every caller first, with no behavior change, so the
> >>> follow-up only replaces the type_register_static() call.
> >>>
> >>> Each machine file gains a class_init function, a TypeInfo, and a
> >>> type_init
> >>> function that calls type_register_static(). The last patch removes
> >>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
>
> Macros help reading the code not saving typing. If the actual
> functionality is buried in a lot of boiler plate it's harder to understand
> and spot bugs so putting the unintresting boiler plate behind a macro is
> better even if you need a separate version for different cases. Then the
> code that uses the macro will be much more obvious and not just a lot of

I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are
not defined properly
that causes them to not be extended easily.

DEFINE_TYPES is another example, use them can extend easily, how about
always use DEFINE_TYPES?
Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*?


> boiler plate.
>
> Regards,
> BALATON Zoltan


--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 2804 bytes --]

On Sat, 31 Oct 2026, Yonggang Luo wrote:
> On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>
>> On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
>>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
>>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
>>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
>>>>> type_init
>>>>> function that calls type_register_static(). A later change needs to
>>>>> pass a
>>>>
>>>> That's the point of the macro to hide the boiler plate code.
>>>>
>>>>> target mask into that registration, and the macros have no parameter
>>>>> for it.
>>>>
>>>> Couldn't you just change the macros to take that parameter instead of
>>>> expanding it everywhere?
>>>>
>>>
>>> Problem of macros is that they don't have default parameters, so you
>>> need variants for everything:
>>>
>>> DEFINE_MACHINE
>>> DEFINE_MACHINE_EXTENDED
>>> DEFINE_MACHINE_WITH_INTERFACES
>>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
>>> and now would need a new variant, with variant for other existing ones.
>>>
>>> In the end, it's just simpler to remove this and add the boilerplate.
>>> It's written once and never modified, so using a macro just save typing
>>> those lines once.
>>>
>>>> Regards,
>>>> BALATON Zoltan
>>>>
>>>>> This series expands every caller first, with no behavior change, so the
>>>>> follow-up only replaces the type_register_static() call.
>>>>>
>>>>> Each machine file gains a class_init function, a TypeInfo, and a
>>>>> type_init
>>>>> function that calls type_register_static(). The last patch removes
>>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
>>
>> Macros help reading the code not saving typing. If the actual
>> functionality is buried in a lot of boiler plate it's harder to understand
>> and spot bugs so putting the unintresting boiler plate behind a macro is
>> better even if you need a separate version for different cases. Then the
>> code that uses the macro will be much more obvious and not just a lot of
>
> I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are
> not defined properly
> that causes them to not be extended easily.
>
> DEFINE_TYPES is another example, use them can extend easily, how about
> always use DEFINE_TYPES?
> Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*?

Maybe I'm missing the problem but DEFINE_MACHINE macros are just 
convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't you add 
the needed parameter to DEFINE_MACHINE_EXTENDED and use that for machines 
that need it, or if it's needed by all machines then make the new 
parameter required and add it to all convenience wrappers too so you can 
keep using DEFINE_MACHINE* and just need to add one parameter to it in 
machines?

Regards,
BALATON Zoltan

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

On Sun, Nov 1, 2026 at 1:06 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Sat, 31 Oct 2026, Yonggang Luo wrote:
> > On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>
> >> On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
> >>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> >>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
> >>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
> >>>>> type_init
> >>>>> function that calls type_register_static(). A later change needs to
> >>>>> pass a
> >>>>
> >>>> That's the point of the macro to hide the boiler plate code.
> >>>>
> >>>>> target mask into that registration, and the macros have no parameter
> >>>>> for it.
> >>>>
> >>>> Couldn't you just change the macros to take that parameter instead of
> >>>> expanding it everywhere?
> >>>>
> >>>
> >>> Problem of macros is that they don't have default parameters, so you
> >>> need variants for everything:
> >>>
> >>> DEFINE_MACHINE
> >>> DEFINE_MACHINE_EXTENDED
> >>> DEFINE_MACHINE_WITH_INTERFACES
> >>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> >>> and now would need a new variant, with variant for other existing ones.
> >>>
> >>> In the end, it's just simpler to remove this and add the boilerplate.
> >>> It's written once and never modified, so using a macro just save typing
> >>> those lines once.
> >>>
> >>>> Regards,
> >>>> BALATON Zoltan
> >>>>
> >>>>> This series expands every caller first, with no behavior change, so the
> >>>>> follow-up only replaces the type_register_static() call.
> >>>>>
> >>>>> Each machine file gains a class_init function, a TypeInfo, and a
> >>>>> type_init
> >>>>> function that calls type_register_static(). The last patch removes
> >>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
> >>
> >> Macros help reading the code not saving typing. If the actual
> >> functionality is buried in a lot of boiler plate it's harder to understand
> >> and spot bugs so putting the unintresting boiler plate behind a macro is
> >> better even if you need a separate version for different cases. Then the
> >> code that uses the macro will be much more obvious and not just a lot of
> >
> > I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are
> > not defined properly
> > that causes them to not be extended easily.
> >
> > DEFINE_TYPES is another example, use them can extend easily, how about
> > always use DEFINE_TYPES?
> > Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*?
>
> Maybe I'm missing the problem but DEFINE_MACHINE macros are just
> convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't you add
> the needed parameter to DEFINE_MACHINE_EXTENDED and use that for machines
> that need it, or if it's needed by all machines then make the new
> parameter required and add it to all convenience wrappers too so you can
> keep using DEFINE_MACHINE* and just need to add one parameter to it in
> machines?

That's the issue, add parameter to DEFINE_MACHINE_EXTENDED means all
calls to it also need
to be changed, that means touch many $target_arch files. currently
it's 13. But after these
changes, there will be much more usage on it, and if we want to add
more parameters or attributes
to it, it will be a new tree-wide change.

And DEFINE_TYPES do not suffer from such issues. As the TypeInfo[] is
explicit defined for
DEFINE_TYPES

>
> Regards,
> BALATON Zoltan



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 4021 bytes --]

On Sun, 1 Nov 2026, Yonggang Luo wrote:
> On Sun, Nov 1, 2026 at 1:06 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>
>> On Sat, 31 Oct 2026, Yonggang Luo wrote:
>>> On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>
>>>> On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
>>>>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
>>>>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
>>>>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
>>>>>>> type_init
>>>>>>> function that calls type_register_static(). A later change needs to
>>>>>>> pass a
>>>>>>
>>>>>> That's the point of the macro to hide the boiler plate code.
>>>>>>
>>>>>>> target mask into that registration, and the macros have no parameter
>>>>>>> for it.
>>>>>>
>>>>>> Couldn't you just change the macros to take that parameter instead of
>>>>>> expanding it everywhere?
>>>>>>
>>>>>
>>>>> Problem of macros is that they don't have default parameters, so you
>>>>> need variants for everything:
>>>>>
>>>>> DEFINE_MACHINE
>>>>> DEFINE_MACHINE_EXTENDED
>>>>> DEFINE_MACHINE_WITH_INTERFACES
>>>>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
>>>>> and now would need a new variant, with variant for other existing ones.
>>>>>
>>>>> In the end, it's just simpler to remove this and add the boilerplate.
>>>>> It's written once and never modified, so using a macro just save typing
>>>>> those lines once.
>>>>>
>>>>>> Regards,
>>>>>> BALATON Zoltan
>>>>>>
>>>>>>> This series expands every caller first, with no behavior change, so the
>>>>>>> follow-up only replaces the type_register_static() call.
>>>>>>>
>>>>>>> Each machine file gains a class_init function, a TypeInfo, and a
>>>>>>> type_init
>>>>>>> function that calls type_register_static(). The last patch removes
>>>>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
>>>>
>>>> Macros help reading the code not saving typing. If the actual
>>>> functionality is buried in a lot of boiler plate it's harder to understand
>>>> and spot bugs so putting the unintresting boiler plate behind a macro is
>>>> better even if you need a separate version for different cases. Then the
>>>> code that uses the macro will be much more obvious and not just a lot of
>>>
>>> I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are
>>> not defined properly
>>> that causes them to not be extended easily.
>>>
>>> DEFINE_TYPES is another example, use them can extend easily, how about
>>> always use DEFINE_TYPES?
>>> Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*?
>>
>> Maybe I'm missing the problem but DEFINE_MACHINE macros are just
>> convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't you add
>> the needed parameter to DEFINE_MACHINE_EXTENDED and use that for machines
>> that need it, or if it's needed by all machines then make the new
>> parameter required and add it to all convenience wrappers too so you can
>> keep using DEFINE_MACHINE* and just need to add one parameter to it in
>> machines?
>
> That's the issue, add parameter to DEFINE_MACHINE_EXTENDED means all
> calls to it also need
> to be changed, that means touch many $target_arch files. currently
> it's 13. But after these

That's not different from expanding the macro which would touch the same 
files.

> changes, there will be much more usage on it, and if we want to add
> more parameters or attributes
> to it, it will be a new tree-wide change.

Do you expect to need more parameters? Can't you add them at once then?

> And DEFINE_TYPES do not suffer from such issues. As the TypeInfo[] is
> explicit defined for
> DEFINE_TYPES

My point is that keeping the boiler plate as little as possible makes the 
code more readable. DEFINE_TYPES hides some of the boiler plate, 
DEFINE_MACHINE hides even more so converting to DEFINE_TYPES would expose 
some even if it's better than no macro at all.

What exactly are the parameters missing from DEFINE_MACHINE_EXTENDED that 
need to be added?

Regards,
BALATON Zoltan

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

On Sun, Nov 1, 2026 at 7:29 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Sun, 1 Nov 2026, Yonggang Luo wrote:
> > On Sun, Nov 1, 2026 at 1:06 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>
> >> On Sat, 31 Oct 2026, Yonggang Luo wrote:
> >>> On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>>>
> >>>> On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
> >>>>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> >>>>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
> >>>>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
> >>>>>>> type_init
> >>>>>>> function that calls type_register_static(). A later change needs to
> >>>>>>> pass a
> >>>>>>
> >>>>>> That's the point of the macro to hide the boiler plate code.
> >>>>>>
> >>>>>>> target mask into that registration, and the macros have no parameter
> >>>>>>> for it.
> >>>>>>
> >>>>>> Couldn't you just change the macros to take that parameter instead of
> >>>>>> expanding it everywhere?
> >>>>>>
> >>>>>
> >>>>> Problem of macros is that they don't have default parameters, so you
> >>>>> need variants for everything:
> >>>>>
> >>>>> DEFINE_MACHINE
> >>>>> DEFINE_MACHINE_EXTENDED
> >>>>> DEFINE_MACHINE_WITH_INTERFACES
> >>>>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> >>>>> and now would need a new variant, with variant for other existing ones.
> >>>>>
> >>>>> In the end, it's just simpler to remove this and add the boilerplate.
> >>>>> It's written once and never modified, so using a macro just save typing
> >>>>> those lines once.
> >>>>>
> >>>>>> Regards,
> >>>>>> BALATON Zoltan
> >>>>>>
> >>>>>>> This series expands every caller first, with no behavior change, so the
> >>>>>>> follow-up only replaces the type_register_static() call.
> >>>>>>>
> >>>>>>> Each machine file gains a class_init function, a TypeInfo, and a
> >>>>>>> type_init
> >>>>>>> function that calls type_register_static(). The last patch removes
> >>>>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
> >>>>
> >>>> Macros help reading the code not saving typing. If the actual
> >>>> functionality is buried in a lot of boiler plate it's harder to understand
> >>>> and spot bugs so putting the unintresting boiler plate behind a macro is
> >>>> better even if you need a separate version for different cases. Then the
> >>>> code that uses the macro will be much more obvious and not just a lot of
> >>>
> >>> I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are
> >>> not defined properly
> >>> that causes them to not be extended easily.
> >>>
> >>> DEFINE_TYPES is another example, use them can extend easily, how about
> >>> always use DEFINE_TYPES?
> >>> Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*?
> >>
> >> Maybe I'm missing the problem but DEFINE_MACHINE macros are just
> >> convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't you add
> >> the needed parameter to DEFINE_MACHINE_EXTENDED and use that for machines
> >> that need it, or if it's needed by all machines then make the new
> >> parameter required and add it to all convenience wrappers too so you can
> >> keep using DEFINE_MACHINE* and just need to add one parameter to it in
> >> machines?
> >
> > That's the issue, add parameter to DEFINE_MACHINE_EXTENDED means all
> > calls to it also need
> > to be changed, that means touch many $target_arch files. currently
> > it's 13. But after these
>
> That's not different from expanding the macro which would touch the same
> files.
>
> > changes, there will be much more usage on it, and if we want to add
> > more parameters or attributes
> > to it, it will be a new tree-wide change.
>
> Do you expect to need more parameters? Can't you add them at once then?
>
> > And DEFINE_TYPES do not suffer from such issues. As the TypeInfo[] is
> > explicit defined for
> > DEFINE_TYPES
>
> My point is that keeping the boiler plate as little as possible makes the
> code more readable. DEFINE_TYPES hides some of the boiler plate,
> DEFINE_MACHINE hides even more so converting to DEFINE_TYPES would expose
> some even if it's better than no macro at all.
>
> What exactly are the parameters missing from DEFINE_MACHINE_EXTENDED that
> need to be added?

Hi BALATON
the things we faced is we first is to add TypeInfo::is_available parameter to
DEFINE_MACHINE_EXTENDED, and have more usage of it.
Then we will add targets:uint64_t parameter to DEFINE_MACHINE_EXTENDED, this is
a prepare to remove TypeInfo::is_available parameter from
DEFINE_MACHINE_EXTENDED,

And finally, once all usage of TypeInfo::is_available can be replaced with
targets:uint64_t, then we finally need to remove
TypeInfo::is_available parameter from DEFINE_MACHINE_EXTENDED,

That's what I am facing now. And the explicit
static const TypeInfo xxx_machine_typeinfo = {
    .name       = MACHINE_TYPE_NAME("xxx"),
    .parent     = TYPE_MACHINE,
    .class_init = xxx_machine_class_init,
};

Will help me avoid the issue. And I think this is a little boilerplate
and very explicit.


And the
    .instance_size = sizeof(MachineState),
is indeed not needed, they sharing TYPE_MACHINE's sizeof(MachineState)
is enough.
Even though DEFINE_MACHINE expands to .instance_size =
sizeof(MachineState), and it's redundant.
So I think convert to DEFINE_TYPES would be a good alternative to this
issue, less boilerplate(not none)
And dealt with the issue we faced.

What do you think about this idea, BALATON

>
> Regards,
> BALATON Zoltan



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 6587 bytes --]

On Sun, 1 Nov 2026, Yonggang Luo wrote:
> On Sun, Nov 1, 2026 at 7:29 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>
>> On Sun, 1 Nov 2026, Yonggang Luo wrote:
>>> On Sun, Nov 1, 2026 at 1:06 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>
>>>> On Sat, 31 Oct 2026, Yonggang Luo wrote:
>>>>> On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>>>
>>>>>> On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
>>>>>>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
>>>>>>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
>>>>>>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
>>>>>>>>> type_init
>>>>>>>>> function that calls type_register_static(). A later change needs to
>>>>>>>>> pass a
>>>>>>>>
>>>>>>>> That's the point of the macro to hide the boiler plate code.
>>>>>>>>
>>>>>>>>> target mask into that registration, and the macros have no parameter
>>>>>>>>> for it.
>>>>>>>>
>>>>>>>> Couldn't you just change the macros to take that parameter instead of
>>>>>>>> expanding it everywhere?
>>>>>>>>
>>>>>>>
>>>>>>> Problem of macros is that they don't have default parameters, so you
>>>>>>> need variants for everything:
>>>>>>>
>>>>>>> DEFINE_MACHINE
>>>>>>> DEFINE_MACHINE_EXTENDED
>>>>>>> DEFINE_MACHINE_WITH_INTERFACES
>>>>>>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
>>>>>>> and now would need a new variant, with variant for other existing ones.
>>>>>>>
>>>>>>> In the end, it's just simpler to remove this and add the boilerplate.
>>>>>>> It's written once and never modified, so using a macro just save typing
>>>>>>> those lines once.
>>>>>>>
>>>>>>>> Regards,
>>>>>>>> BALATON Zoltan
>>>>>>>>
>>>>>>>>> This series expands every caller first, with no behavior change, so the
>>>>>>>>> follow-up only replaces the type_register_static() call.
>>>>>>>>>
>>>>>>>>> Each machine file gains a class_init function, a TypeInfo, and a
>>>>>>>>> type_init
>>>>>>>>> function that calls type_register_static(). The last patch removes
>>>>>>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
>>>>>>
>>>>>> Macros help reading the code not saving typing. If the actual
>>>>>> functionality is buried in a lot of boiler plate it's harder to understand
>>>>>> and spot bugs so putting the unintresting boiler plate behind a macro is
>>>>>> better even if you need a separate version for different cases. Then the
>>>>>> code that uses the macro will be much more obvious and not just a lot of
>>>>>
>>>>> I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are
>>>>> not defined properly
>>>>> that causes them to not be extended easily.
>>>>>
>>>>> DEFINE_TYPES is another example, use them can extend easily, how about
>>>>> always use DEFINE_TYPES?
>>>>> Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*?
>>>>
>>>> Maybe I'm missing the problem but DEFINE_MACHINE macros are just
>>>> convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't you add
>>>> the needed parameter to DEFINE_MACHINE_EXTENDED and use that for machines
>>>> that need it, or if it's needed by all machines then make the new
>>>> parameter required and add it to all convenience wrappers too so you can
>>>> keep using DEFINE_MACHINE* and just need to add one parameter to it in
>>>> machines?
>>>
>>> That's the issue, add parameter to DEFINE_MACHINE_EXTENDED means all
>>> calls to it also need
>>> to be changed, that means touch many $target_arch files. currently
>>> it's 13. But after these
>>
>> That's not different from expanding the macro which would touch the same
>> files.
>>
>>> changes, there will be much more usage on it, and if we want to add
>>> more parameters or attributes
>>> to it, it will be a new tree-wide change.
>>
>> Do you expect to need more parameters? Can't you add them at once then?
>>
>>> And DEFINE_TYPES do not suffer from such issues. As the TypeInfo[] is
>>> explicit defined for
>>> DEFINE_TYPES
>>
>> My point is that keeping the boiler plate as little as possible makes the
>> code more readable. DEFINE_TYPES hides some of the boiler plate,
>> DEFINE_MACHINE hides even more so converting to DEFINE_TYPES would expose
>> some even if it's better than no macro at all.
>>
>> What exactly are the parameters missing from DEFINE_MACHINE_EXTENDED that
>> need to be added?
>
> Hi BALATON
> the things we faced is we first is to add TypeInfo::is_available parameter to
> DEFINE_MACHINE_EXTENDED, and have more usage of it.
> Then we will add targets:uint64_t parameter to DEFINE_MACHINE_EXTENDED, this is
> a prepare to remove TypeInfo::is_available parameter from
> DEFINE_MACHINE_EXTENDED,
>
> And finally, once all usage of TypeInfo::is_available can be replaced with
> targets:uint64_t, then we finally need to remove
> TypeInfo::is_available parameter from DEFINE_MACHINE_EXTENDED,

Is there a way to avoid the temporary is_available churn and introduce the 
targets:uint64_t right away? (I'm not following this so I don't really 
know what you're talking about just looks like there's some churn here 
which might be good to awoid anyway independent of these macros.)

> That's what I am facing now. And the explicit
> static const TypeInfo xxx_machine_typeinfo = {
>    .name       = MACHINE_TYPE_NAME("xxx"),
>    .parent     = TYPE_MACHINE,
>    .class_init = xxx_machine_class_init,
> };
>
> Will help me avoid the issue. And I think this is a little boilerplate
> and very explicit.

That's not all DEFINE_MACHINE hides though. It's longer with .abstract, 
.secure and .iterfaces plus the machine initfn that would also need to be 
expanded if you used DEFINE_TYPES.

Is this conversion needed for all machines using all DEFINE_MACHINE 
variants or only some of them? If the latter why not convert those to 
DEFINE_MACHINE_EXTENDED and then only that macro needs to be changed with 
other wrappers passing a default value without needing a new parameter. 
That does not work if all machines need to do this but even then, keeping 
the macro and adding a new required parameter is better in my opinion as 
it keeps boiler plate hidden.

Regards,
BALATON Zoltan

>
> And the
>    .instance_size = sizeof(MachineState),
> is indeed not needed, they sharing TYPE_MACHINE's sizeof(MachineState)
> is enough.
> Even though DEFINE_MACHINE expands to .instance_size =
> sizeof(MachineState), and it's redundant.
> So I think convert to DEFINE_TYPES would be a good alternative to this
> issue, less boilerplate(not none)
> And dealt with the issue we faced.
>
> What do you think about this idea, BALATON
>
>>
>> Regards,
>> BALATON Zoltan
>
>
>
>

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

On Mon, Nov 2, 2026 at 4:57 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Sun, 1 Nov 2026, Yonggang Luo wrote:
> > On Sun, Nov 1, 2026 at 7:29 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>
> >> On Sun, 1 Nov 2026, Yonggang Luo wrote:
> >>> On Sun, Nov 1, 2026 at 1:06 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>>>
> >>>> On Sat, 31 Oct 2026, Yonggang Luo wrote:
> >>>>> On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>>>>>
> >>>>>> On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
> >>>>>>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> >>>>>>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
> >>>>>>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
> >>>>>>>>> type_init
> >>>>>>>>> function that calls type_register_static(). A later change needs to
> >>>>>>>>> pass a
> >>>>>>>>
> >>>>>>>> That's the point of the macro to hide the boiler plate code.
> >>>>>>>>
> >>>>>>>>> target mask into that registration, and the macros have no parameter
> >>>>>>>>> for it.
> >>>>>>>>
> >>>>>>>> Couldn't you just change the macros to take that parameter instead of
> >>>>>>>> expanding it everywhere?
> >>>>>>>>
> >>>>>>>
> >>>>>>> Problem of macros is that they don't have default parameters, so you
> >>>>>>> need variants for everything:
> >>>>>>>
> >>>>>>> DEFINE_MACHINE
> >>>>>>> DEFINE_MACHINE_EXTENDED
> >>>>>>> DEFINE_MACHINE_WITH_INTERFACES
> >>>>>>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> >>>>>>> and now would need a new variant, with variant for other existing ones.
> >>>>>>>
> >>>>>>> In the end, it's just simpler to remove this and add the boilerplate.
> >>>>>>> It's written once and never modified, so using a macro just save typing
> >>>>>>> those lines once.
> >>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> BALATON Zoltan
> >>>>>>>>
> >>>>>>>>> This series expands every caller first, with no behavior change, so the
> >>>>>>>>> follow-up only replaces the type_register_static() call.
> >>>>>>>>>
> >>>>>>>>> Each machine file gains a class_init function, a TypeInfo, and a
> >>>>>>>>> type_init
> >>>>>>>>> function that calls type_register_static(). The last patch removes
> >>>>>>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
> >>>>>>
> >>>>>> Macros help reading the code not saving typing. If the actual
> >>>>>> functionality is buried in a lot of boiler plate it's harder to understand
> >>>>>> and spot bugs so putting the unintresting boiler plate behind a macro is
> >>>>>> better even if you need a separate version for different cases. Then the
> >>>>>> code that uses the macro will be much more obvious and not just a lot of
> >>>>>
> >>>>> I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are
> >>>>> not defined properly
> >>>>> that causes them to not be extended easily.
> >>>>>
> >>>>> DEFINE_TYPES is another example, use them can extend easily, how about
> >>>>> always use DEFINE_TYPES?
> >>>>> Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*?
> >>>>
> >>>> Maybe I'm missing the problem but DEFINE_MACHINE macros are just
> >>>> convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't you add
> >>>> the needed parameter to DEFINE_MACHINE_EXTENDED and use that for machines
> >>>> that need it, or if it's needed by all machines then make the new
> >>>> parameter required and add it to all convenience wrappers too so you can
> >>>> keep using DEFINE_MACHINE* and just need to add one parameter to it in
> >>>> machines?
> >>>
> >>> That's the issue, add parameter to DEFINE_MACHINE_EXTENDED means all
> >>> calls to it also need
> >>> to be changed, that means touch many $target_arch files. currently
> >>> it's 13. But after these
> >>
> >> That's not different from expanding the macro which would touch the same
> >> files.
> >>
> >>> changes, there will be much more usage on it, and if we want to add
> >>> more parameters or attributes
> >>> to it, it will be a new tree-wide change.
> >>
> >> Do you expect to need more parameters? Can't you add them at once then?
> >>
> >>> And DEFINE_TYPES do not suffer from such issues. As the TypeInfo[] is
> >>> explicit defined for
> >>> DEFINE_TYPES
> >>
> >> My point is that keeping the boiler plate as little as possible makes the
> >> code more readable. DEFINE_TYPES hides some of the boiler plate,
> >> DEFINE_MACHINE hides even more so converting to DEFINE_TYPES would expose
> >> some even if it's better than no macro at all.
> >>
> >> What exactly are the parameters missing from DEFINE_MACHINE_EXTENDED that
> >> need to be added?
> >
> > Hi BALATON
> > the things we faced is we first is to add TypeInfo::is_available parameter to
> > DEFINE_MACHINE_EXTENDED, and have more usage of it.
> > Then we will add targets:uint64_t parameter to DEFINE_MACHINE_EXTENDED, this is
> > a prepare to remove TypeInfo::is_available parameter from
> > DEFINE_MACHINE_EXTENDED,
> >
> > And finally, once all usage of TypeInfo::is_available can be replaced with
> > targets:uint64_t, then we finally need to remove
> > TypeInfo::is_available parameter from DEFINE_MACHINE_EXTENDED,
>
> Is there a way to avoid the temporary is_available churn and introduce the
> targets:uint64_t right away? (I'm not following this so I don't really
> know what you're talking about just looks like there's some churn here
> which might be good to awoid anyway independent of these macros.)
>
> > That's what I am facing now. And the explicit
> > static const TypeInfo xxx_machine_typeinfo = {
> >    .name       = MACHINE_TYPE_NAME("xxx"),
> >    .parent     = TYPE_MACHINE,
> >    .class_init = xxx_machine_class_init,
> > };
> >
> > Will help me avoid the issue. And I think this is a little boilerplate
> > and very explicit.
>
> That's not all DEFINE_MACHINE hides though. It's longer with .abstract,
> .secure and .iterfaces plus the machine initfn that would also need to be
> expanded if you used DEFINE_TYPES.
>
> Is this conversion needed for all machines using all DEFINE_MACHINE

At the end, only "none" machine do not have targets parameter or
(QEMU_ARCH_ALL), as that's the sole
machine that supports all targets.

> variants or only some of them? If the latter why not convert those to




> DEFINE_MACHINE_EXTENDED and then only that macro needs to be changed with
> other wrappers passing a default value without needing a new parameter.
> That does not work if all machines need to do this but even then, keeping
> the macro and adding a new required parameter is better in my opinion as
> it keeps boiler plate hidden.

Another option is keep DEFINE_MACHINE and introduce DEFINE_MACHINE_TARGETS
and remove DEFINE_MACHINE_EXTENDED, and we only use DEFINE_MACHINE for
simple case,
that is parent is TYPE_MACHINE and have no custom type and no more
attributes assigned.
DEFINE_MACHINE_EXTENDED is too verbose, when calling it, it less clear
than calling to DEFINE_MACHINE.
And if we want to set more attributes to TypeInfo, just expand it to
use type_init or DEFINE_TYPES, how about this way.

This will be something like:

#define DEFINE_MACHINE_TARGETS(namestr, machine_initfn, targets) \
    static void machine_initfn##_class_init(ObjectClass *oc, const void *data) \
    { \
        MachineClass *mc = MACHINE_CLASS(oc); \
        machine_initfn(mc); \
    } \
    static const TypeInfo machine_initfn##_typeinfo = { \
        .name       = MACHINE_TYPE_NAME(namestr), \
        .parent     = TYPE_MACHINE, \
        .class_init = machine_initfn##_class_init, \
    }; \
    static void machine_initfn##_register_types(void) \
    { \
        type_register_targets(&machine_initfn##_typeinfo, targets); \
    } \
    type_init(machine_initfn##_register_types)

/* Implicitly insecure */
#define DEFINE_MACHINE(namestr, machine_initfn) \
    DEFINE_MACHINE_TARGETS(namestr, machine_initfn, QEMU_ARCH_ALL) \

As the many call is to DEFINE_MACHINE.

And after all conversion, all existing usage of DEFINE_MACHINE will be
converted to
DEFINE_MACHINE_TARGETS.
DEFINE_MACHINE will be called for ('none') machine or future heterogeneous
machines


Either way, these patches will be dropped. We will introduce
DEFINE_MACHINE_TARGETS first.

>
> Regards,
> BALATON Zoltan
>
> >
> > And the
> >    .instance_size = sizeof(MachineState),
> > is indeed not needed, they sharing TYPE_MACHINE's sizeof(MachineState)
> > is enough.
> > Even though DEFINE_MACHINE expands to .instance_size =
> > sizeof(MachineState), and it's redundant.
> > So I think convert to DEFINE_TYPES would be a good alternative to this
> > issue, less boilerplate(not none)
> > And dealt with the issue we faced.
> >
> > What do you think about this idea, BALATON
> >
> >>
> >> Regards,
> >> BALATON Zoltan
> >
> >
> >
> >



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 9034 bytes --]

On Mon, 2 Nov 2026, Yonggang Luo wrote:
> On Mon, Nov 2, 2026 at 4:57 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>
>> On Sun, 1 Nov 2026, Yonggang Luo wrote:
>>> On Sun, Nov 1, 2026 at 7:29 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>
>>>> On Sun, 1 Nov 2026, Yonggang Luo wrote:
>>>>> On Sun, Nov 1, 2026 at 1:06 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>>>
>>>>>> On Sat, 31 Oct 2026, Yonggang Luo wrote:
>>>>>>> On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>>>>>
>>>>>>>> On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
>>>>>>>>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
>>>>>>>>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
>>>>>>>>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
>>>>>>>>>>> type_init
>>>>>>>>>>> function that calls type_register_static(). A later change needs to
>>>>>>>>>>> pass a
>>>>>>>>>>
>>>>>>>>>> That's the point of the macro to hide the boiler plate code.
>>>>>>>>>>
>>>>>>>>>>> target mask into that registration, and the macros have no parameter
>>>>>>>>>>> for it.
>>>>>>>>>>
>>>>>>>>>> Couldn't you just change the macros to take that parameter instead of
>>>>>>>>>> expanding it everywhere?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Problem of macros is that they don't have default parameters, so you
>>>>>>>>> need variants for everything:
>>>>>>>>>
>>>>>>>>> DEFINE_MACHINE
>>>>>>>>> DEFINE_MACHINE_EXTENDED
>>>>>>>>> DEFINE_MACHINE_WITH_INTERFACES
>>>>>>>>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
>>>>>>>>> and now would need a new variant, with variant for other existing ones.
>>>>>>>>>
>>>>>>>>> In the end, it's just simpler to remove this and add the boilerplate.
>>>>>>>>> It's written once and never modified, so using a macro just save typing
>>>>>>>>> those lines once.
>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> BALATON Zoltan
>>>>>>>>>>
>>>>>>>>>>> This series expands every caller first, with no behavior change, so the
>>>>>>>>>>> follow-up only replaces the type_register_static() call.
>>>>>>>>>>>
>>>>>>>>>>> Each machine file gains a class_init function, a TypeInfo, and a
>>>>>>>>>>> type_init
>>>>>>>>>>> function that calls type_register_static(). The last patch removes
>>>>>>>>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
>>>>>>>>
>>>>>>>> Macros help reading the code not saving typing. If the actual
>>>>>>>> functionality is buried in a lot of boiler plate it's harder to understand
>>>>>>>> and spot bugs so putting the unintresting boiler plate behind a macro is
>>>>>>>> better even if you need a separate version for different cases. Then the
>>>>>>>> code that uses the macro will be much more obvious and not just a lot of
>>>>>>>
>>>>>>> I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are
>>>>>>> not defined properly
>>>>>>> that causes them to not be extended easily.
>>>>>>>
>>>>>>> DEFINE_TYPES is another example, use them can extend easily, how about
>>>>>>> always use DEFINE_TYPES?
>>>>>>> Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*?
>>>>>>
>>>>>> Maybe I'm missing the problem but DEFINE_MACHINE macros are just
>>>>>> convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't you add
>>>>>> the needed parameter to DEFINE_MACHINE_EXTENDED and use that for machines
>>>>>> that need it, or if it's needed by all machines then make the new
>>>>>> parameter required and add it to all convenience wrappers too so you can
>>>>>> keep using DEFINE_MACHINE* and just need to add one parameter to it in
>>>>>> machines?
>>>>>
>>>>> That's the issue, add parameter to DEFINE_MACHINE_EXTENDED means all
>>>>> calls to it also need
>>>>> to be changed, that means touch many $target_arch files. currently
>>>>> it's 13. But after these
>>>>
>>>> That's not different from expanding the macro which would touch the same
>>>> files.
>>>>
>>>>> changes, there will be much more usage on it, and if we want to add
>>>>> more parameters or attributes
>>>>> to it, it will be a new tree-wide change.
>>>>
>>>> Do you expect to need more parameters? Can't you add them at once then?
>>>>
>>>>> And DEFINE_TYPES do not suffer from such issues. As the TypeInfo[] is
>>>>> explicit defined for
>>>>> DEFINE_TYPES
>>>>
>>>> My point is that keeping the boiler plate as little as possible makes the
>>>> code more readable. DEFINE_TYPES hides some of the boiler plate,
>>>> DEFINE_MACHINE hides even more so converting to DEFINE_TYPES would expose
>>>> some even if it's better than no macro at all.
>>>>
>>>> What exactly are the parameters missing from DEFINE_MACHINE_EXTENDED that
>>>> need to be added?
>>>
>>> Hi BALATON
>>> the things we faced is we first is to add TypeInfo::is_available parameter to
>>> DEFINE_MACHINE_EXTENDED, and have more usage of it.
>>> Then we will add targets:uint64_t parameter to DEFINE_MACHINE_EXTENDED, this is
>>> a prepare to remove TypeInfo::is_available parameter from
>>> DEFINE_MACHINE_EXTENDED,
>>>
>>> And finally, once all usage of TypeInfo::is_available can be replaced with
>>> targets:uint64_t, then we finally need to remove
>>> TypeInfo::is_available parameter from DEFINE_MACHINE_EXTENDED,
>>
>> Is there a way to avoid the temporary is_available churn and introduce the
>> targets:uint64_t right away? (I'm not following this so I don't really
>> know what you're talking about just looks like there's some churn here
>> which might be good to awoid anyway independent of these macros.)
>>
>>> That's what I am facing now. And the explicit
>>> static const TypeInfo xxx_machine_typeinfo = {
>>>    .name       = MACHINE_TYPE_NAME("xxx"),
>>>    .parent     = TYPE_MACHINE,
>>>    .class_init = xxx_machine_class_init,
>>> };
>>>
>>> Will help me avoid the issue. And I think this is a little boilerplate
>>> and very explicit.
>>
>> That's not all DEFINE_MACHINE hides though. It's longer with .abstract,
>> .secure and .iterfaces plus the machine initfn that would also need to be
>> expanded if you used DEFINE_TYPES.
>>
>> Is this conversion needed for all machines using all DEFINE_MACHINE
>
> At the end, only "none" machine do not have targets parameter or
> (QEMU_ARCH_ALL), as that's the sole
> machine that supports all targets.
>
>> variants or only some of them? If the latter why not convert those to
>
>
>
>
>> DEFINE_MACHINE_EXTENDED and then only that macro needs to be changed with
>> other wrappers passing a default value without needing a new parameter.
>> That does not work if all machines need to do this but even then, keeping
>> the macro and adding a new required parameter is better in my opinion as
>> it keeps boiler plate hidden.
>
> Another option is keep DEFINE_MACHINE and introduce DEFINE_MACHINE_TARGETS
> and remove DEFINE_MACHINE_EXTENDED, and we only use DEFINE_MACHINE for
> simple case,
> that is parent is TYPE_MACHINE and have no custom type and no more
> attributes assigned.
> DEFINE_MACHINE_EXTENDED is too verbose, when calling it, it less clear
> than calling to DEFINE_MACHINE.
> And if we want to set more attributes to TypeInfo, just expand it to
> use type_init or DEFINE_TYPES, how about this way.
>
> This will be something like:
>
> #define DEFINE_MACHINE_TARGETS(namestr, machine_initfn, targets) \
>    static void machine_initfn##_class_init(ObjectClass *oc, const void *data) \
>    { \
>        MachineClass *mc = MACHINE_CLASS(oc); \
>        machine_initfn(mc); \
>    } \
>    static const TypeInfo machine_initfn##_typeinfo = { \
>        .name       = MACHINE_TYPE_NAME(namestr), \
>        .parent     = TYPE_MACHINE, \
>        .class_init = machine_initfn##_class_init, \
>    }; \
>    static void machine_initfn##_register_types(void) \
>    { \
>        type_register_targets(&machine_initfn##_typeinfo, targets); \
>    } \
>    type_init(machine_initfn##_register_types)
>
> /* Implicitly insecure */
> #define DEFINE_MACHINE(namestr, machine_initfn) \
>    DEFINE_MACHINE_TARGETS(namestr, machine_initfn, QEMU_ARCH_ALL) \
>
> As the many call is to DEFINE_MACHINE.
>
> And after all conversion, all existing usage of DEFINE_MACHINE will be
> converted to
> DEFINE_MACHINE_TARGETS.
> DEFINE_MACHINE will be called for ('none') machine or future heterogeneous
> machines
>
>
> Either way, these patches will be dropped. We will introduce
> DEFINE_MACHINE_TARGETS first.

I think I'm lost and cannot follow what you want. As far as I understood 
you want to add a new field "target" to machine TypeInfo but instead of 
adding that straight away you proposed to first add is_available then 
later replace that with target. I asked why do you need is_available and 
not add target right away?

Then if this target parameter will be needed for all machines why can't 
you add that to all DEFINE_MACHINE macros as a required parameter and set 
it for all machines passing it through to DEFINE_MACHINE_EXTENDED which 
sets in the TypeInfo. That way no machines need changing other than adding 
the target parameter to the existing DEFINE_MACHINE calls.

What am I missing?

Regards,
BALATON Zoltan

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

On Mon, Nov 2, 2026 at 10:56 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Mon, 2 Nov 2026, Yonggang Luo wrote:
> > On Mon, Nov 2, 2026 at 4:57 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>
> >> On Sun, 1 Nov 2026, Yonggang Luo wrote:
> >>> On Sun, Nov 1, 2026 at 7:29 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>>>
> >>>> On Sun, 1 Nov 2026, Yonggang Luo wrote:
> >>>>> On Sun, Nov 1, 2026 at 1:06 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>>>>>
> >>>>>> On Sat, 31 Oct 2026, Yonggang Luo wrote:
> >>>>>>> On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>>>>>>>
> >>>>>>>> On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
> >>>>>>>>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> >>>>>>>>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
> >>>>>>>>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
> >>>>>>>>>>> type_init
> >>>>>>>>>>> function that calls type_register_static(). A later change needs to
> >>>>>>>>>>> pass a
> >>>>>>>>>>
> >>>>>>>>>> That's the point of the macro to hide the boiler plate code.
> >>>>>>>>>>
> >>>>>>>>>>> target mask into that registration, and the macros have no parameter
> >>>>>>>>>>> for it.
> >>>>>>>>>>
> >>>>>>>>>> Couldn't you just change the macros to take that parameter instead of
> >>>>>>>>>> expanding it everywhere?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Problem of macros is that they don't have default parameters, so you
> >>>>>>>>> need variants for everything:
> >>>>>>>>>
> >>>>>>>>> DEFINE_MACHINE
> >>>>>>>>> DEFINE_MACHINE_EXTENDED
> >>>>>>>>> DEFINE_MACHINE_WITH_INTERFACES
> >>>>>>>>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> >>>>>>>>> and now would need a new variant, with variant for other existing ones.
> >>>>>>>>>
> >>>>>>>>> In the end, it's just simpler to remove this and add the boilerplate.
> >>>>>>>>> It's written once and never modified, so using a macro just save typing
> >>>>>>>>> those lines once.
> >>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>> BALATON Zoltan
> >>>>>>>>>>
> >>>>>>>>>>> This series expands every caller first, with no behavior change, so the
> >>>>>>>>>>> follow-up only replaces the type_register_static() call.
> >>>>>>>>>>>
> >>>>>>>>>>> Each machine file gains a class_init function, a TypeInfo, and a
> >>>>>>>>>>> type_init
> >>>>>>>>>>> function that calls type_register_static(). The last patch removes
> >>>>>>>>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
> >>>>>>>>
> >>>>>>>> Macros help reading the code not saving typing. If the actual
> >>>>>>>> functionality is buried in a lot of boiler plate it's harder to understand
> >>>>>>>> and spot bugs so putting the unintresting boiler plate behind a macro is
> >>>>>>>> better even if you need a separate version for different cases. Then the
> >>>>>>>> code that uses the macro will be much more obvious and not just a lot of
> >>>>>>>
> >>>>>>> I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are
> >>>>>>> not defined properly
> >>>>>>> that causes them to not be extended easily.
> >>>>>>>
> >>>>>>> DEFINE_TYPES is another example, use them can extend easily, how about
> >>>>>>> always use DEFINE_TYPES?
> >>>>>>> Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*?
> >>>>>>
> >>>>>> Maybe I'm missing the problem but DEFINE_MACHINE macros are just
> >>>>>> convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't you add
> >>>>>> the needed parameter to DEFINE_MACHINE_EXTENDED and use that for machines
> >>>>>> that need it, or if it's needed by all machines then make the new
> >>>>>> parameter required and add it to all convenience wrappers too so you can
> >>>>>> keep using DEFINE_MACHINE* and just need to add one parameter to it in
> >>>>>> machines?
> >>>>>
> >>>>> That's the issue, add parameter to DEFINE_MACHINE_EXTENDED means all
> >>>>> calls to it also need
> >>>>> to be changed, that means touch many $target_arch files. currently
> >>>>> it's 13. But after these
> >>>>
> >>>> That's not different from expanding the macro which would touch the same
> >>>> files.
> >>>>
> >>>>> changes, there will be much more usage on it, and if we want to add
> >>>>> more parameters or attributes
> >>>>> to it, it will be a new tree-wide change.
> >>>>
> >>>> Do you expect to need more parameters? Can't you add them at once then?
> >>>>
> >>>>> And DEFINE_TYPES do not suffer from such issues. As the TypeInfo[] is
> >>>>> explicit defined for
> >>>>> DEFINE_TYPES
> >>>>
> >>>> My point is that keeping the boiler plate as little as possible makes the
> >>>> code more readable. DEFINE_TYPES hides some of the boiler plate,
> >>>> DEFINE_MACHINE hides even more so converting to DEFINE_TYPES would expose
> >>>> some even if it's better than no macro at all.
> >>>>
> >>>> What exactly are the parameters missing from DEFINE_MACHINE_EXTENDED that
> >>>> need to be added?
> >>>
> >>> Hi BALATON
> >>> the things we faced is we first is to add TypeInfo::is_available parameter to
> >>> DEFINE_MACHINE_EXTENDED, and have more usage of it.
> >>> Then we will add targets:uint64_t parameter to DEFINE_MACHINE_EXTENDED, this is
> >>> a prepare to remove TypeInfo::is_available parameter from
> >>> DEFINE_MACHINE_EXTENDED,
> >>>
> >>> And finally, once all usage of TypeInfo::is_available can be replaced with
> >>> targets:uint64_t, then we finally need to remove
> >>> TypeInfo::is_available parameter from DEFINE_MACHINE_EXTENDED,
> >>
> >> Is there a way to avoid the temporary is_available churn and introduce the
> >> targets:uint64_t right away? (I'm not following this so I don't really
> >> know what you're talking about just looks like there's some churn here
> >> which might be good to awoid anyway independent of these macros.)
> >>
> >>> That's what I am facing now. And the explicit
> >>> static const TypeInfo xxx_machine_typeinfo = {
> >>>    .name       = MACHINE_TYPE_NAME("xxx"),
> >>>    .parent     = TYPE_MACHINE,
> >>>    .class_init = xxx_machine_class_init,
> >>> };
> >>>
> >>> Will help me avoid the issue. And I think this is a little boilerplate
> >>> and very explicit.
> >>
> >> That's not all DEFINE_MACHINE hides though. It's longer with .abstract,
> >> .secure and .iterfaces plus the machine initfn that would also need to be
> >> expanded if you used DEFINE_TYPES.
> >>
> >> Is this conversion needed for all machines using all DEFINE_MACHINE
> >
> > At the end, only "none" machine do not have targets parameter or
> > (QEMU_ARCH_ALL), as that's the sole
> > machine that supports all targets.
> >
> >> variants or only some of them? If the latter why not convert those to
> >
> >
> >
> >
> >> DEFINE_MACHINE_EXTENDED and then only that macro needs to be changed with
> >> other wrappers passing a default value without needing a new parameter.
> >> That does not work if all machines need to do this but even then, keeping
> >> the macro and adding a new required parameter is better in my opinion as
> >> it keeps boiler plate hidden.
> >
> > Another option is keep DEFINE_MACHINE and introduce DEFINE_MACHINE_TARGETS
> > and remove DEFINE_MACHINE_EXTENDED, and we only use DEFINE_MACHINE for
> > simple case,
> > that is parent is TYPE_MACHINE and have no custom type and no more
> > attributes assigned.
> > DEFINE_MACHINE_EXTENDED is too verbose, when calling it, it less clear
> > than calling to DEFINE_MACHINE.
> > And if we want to set more attributes to TypeInfo, just expand it to
> > use type_init or DEFINE_TYPES, how about this way.
> >
> > This will be something like:
> >
> > #define DEFINE_MACHINE_TARGETS(namestr, machine_initfn, targets) \
> >    static void machine_initfn##_class_init(ObjectClass *oc, const void *data) \
> >    { \
> >        MachineClass *mc = MACHINE_CLASS(oc); \
> >        machine_initfn(mc); \
> >    } \
> >    static const TypeInfo machine_initfn##_typeinfo = { \
> >        .name       = MACHINE_TYPE_NAME(namestr), \
> >        .parent     = TYPE_MACHINE, \
> >        .class_init = machine_initfn##_class_init, \
> >    }; \
> >    static void machine_initfn##_register_types(void) \
> >    { \
> >        type_register_targets(&machine_initfn##_typeinfo, targets); \
> >    } \
> >    type_init(machine_initfn##_register_types)
> >
> > /* Implicitly insecure */
> > #define DEFINE_MACHINE(namestr, machine_initfn) \
> >    DEFINE_MACHINE_TARGETS(namestr, machine_initfn, QEMU_ARCH_ALL) \
> >
> > As the many call is to DEFINE_MACHINE.
> >
> > And after all conversion, all existing usage of DEFINE_MACHINE will be
> > converted to
> > DEFINE_MACHINE_TARGETS.
> > DEFINE_MACHINE will be called for ('none') machine or future heterogeneous
> > machines
> >
> >
> > Either way, these patches will be dropped. We will introduce
> > DEFINE_MACHINE_TARGETS first.
>
> I think I'm lost and cannot follow what you want. As far as I understood
> you want to add a new field "target" to machine TypeInfo but instead of
> adding that straight away you proposed to first add is_available then
> later replace that with target. I asked why do you need is_available and
> not add target right away?
>
> Then if this target parameter will be needed for all machines why can't
> you add that to all DEFINE_MACHINE macros as a required parameter and set
> it for all machines passing it through to DEFINE_MACHINE_EXTENDED which
> sets in the TypeInfo. That way no machines need changing other than adding
> the target parameter to the existing DEFINE_MACHINE calls.
>
> What am I missing?
Or sorry, I did not explain well.

I means reshape DEFINE_MACHINE like

https://lore.kernel.org/qemu-devel/20261102194826.1298-1-luoyonggang@gmail.com/T/#u

basically every call to DEFINE_MACHINE needs the targets parameter.
So we can always passing targets parameter for DEFINE_MACHINE.

And I think we can remove DEFINE_MACHINE_EXTENDED, as the call to it is verbose



>
> Regards,
> BALATON Zoltan



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 10675 bytes --]

On Tue, 3 Nov 2026, Yonggang Luo wrote:
> On Mon, Nov 2, 2026 at 10:56 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>
>> On Mon, 2 Nov 2026, Yonggang Luo wrote:
>>> On Mon, Nov 2, 2026 at 4:57 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>
>>>> On Sun, 1 Nov 2026, Yonggang Luo wrote:
>>>>> On Sun, Nov 1, 2026 at 7:29 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>>>
>>>>>> On Sun, 1 Nov 2026, Yonggang Luo wrote:
>>>>>>> On Sun, Nov 1, 2026 at 1:06 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>>>>>
>>>>>>>> On Sat, 31 Oct 2026, Yonggang Luo wrote:
>>>>>>>>> On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>>>>>>>
>>>>>>>>>> On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
>>>>>>>>>>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
>>>>>>>>>>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
>>>>>>>>>>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
>>>>>>>>>>>>> type_init
>>>>>>>>>>>>> function that calls type_register_static(). A later change needs to
>>>>>>>>>>>>> pass a
>>>>>>>>>>>>
>>>>>>>>>>>> That's the point of the macro to hide the boiler plate code.
>>>>>>>>>>>>
>>>>>>>>>>>>> target mask into that registration, and the macros have no parameter
>>>>>>>>>>>>> for it.
>>>>>>>>>>>>
>>>>>>>>>>>> Couldn't you just change the macros to take that parameter instead of
>>>>>>>>>>>> expanding it everywhere?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Problem of macros is that they don't have default parameters, so you
>>>>>>>>>>> need variants for everything:
>>>>>>>>>>>
>>>>>>>>>>> DEFINE_MACHINE
>>>>>>>>>>> DEFINE_MACHINE_EXTENDED
>>>>>>>>>>> DEFINE_MACHINE_WITH_INTERFACES
>>>>>>>>>>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
>>>>>>>>>>> and now would need a new variant, with variant for other existing ones.
>>>>>>>>>>>
>>>>>>>>>>> In the end, it's just simpler to remove this and add the boilerplate.
>>>>>>>>>>> It's written once and never modified, so using a macro just save typing
>>>>>>>>>>> those lines once.
>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> BALATON Zoltan
>>>>>>>>>>>>
>>>>>>>>>>>>> This series expands every caller first, with no behavior change, so the
>>>>>>>>>>>>> follow-up only replaces the type_register_static() call.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Each machine file gains a class_init function, a TypeInfo, and a
>>>>>>>>>>>>> type_init
>>>>>>>>>>>>> function that calls type_register_static(). The last patch removes
>>>>>>>>>>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
>>>>>>>>>>
>>>>>>>>>> Macros help reading the code not saving typing. If the actual
>>>>>>>>>> functionality is buried in a lot of boiler plate it's harder to understand
>>>>>>>>>> and spot bugs so putting the unintresting boiler plate behind a macro is
>>>>>>>>>> better even if you need a separate version for different cases. Then the
>>>>>>>>>> code that uses the macro will be much more obvious and not just a lot of
>>>>>>>>>
>>>>>>>>> I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are
>>>>>>>>> not defined properly
>>>>>>>>> that causes them to not be extended easily.
>>>>>>>>>
>>>>>>>>> DEFINE_TYPES is another example, use them can extend easily, how about
>>>>>>>>> always use DEFINE_TYPES?
>>>>>>>>> Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*?
>>>>>>>>
>>>>>>>> Maybe I'm missing the problem but DEFINE_MACHINE macros are just
>>>>>>>> convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't you add
>>>>>>>> the needed parameter to DEFINE_MACHINE_EXTENDED and use that for machines
>>>>>>>> that need it, or if it's needed by all machines then make the new
>>>>>>>> parameter required and add it to all convenience wrappers too so you can
>>>>>>>> keep using DEFINE_MACHINE* and just need to add one parameter to it in
>>>>>>>> machines?
>>>>>>>
>>>>>>> That's the issue, add parameter to DEFINE_MACHINE_EXTENDED means all
>>>>>>> calls to it also need
>>>>>>> to be changed, that means touch many $target_arch files. currently
>>>>>>> it's 13. But after these
>>>>>>
>>>>>> That's not different from expanding the macro which would touch the same
>>>>>> files.
>>>>>>
>>>>>>> changes, there will be much more usage on it, and if we want to add
>>>>>>> more parameters or attributes
>>>>>>> to it, it will be a new tree-wide change.
>>>>>>
>>>>>> Do you expect to need more parameters? Can't you add them at once then?
>>>>>>
>>>>>>> And DEFINE_TYPES do not suffer from such issues. As the TypeInfo[] is
>>>>>>> explicit defined for
>>>>>>> DEFINE_TYPES
>>>>>>
>>>>>> My point is that keeping the boiler plate as little as possible makes the
>>>>>> code more readable. DEFINE_TYPES hides some of the boiler plate,
>>>>>> DEFINE_MACHINE hides even more so converting to DEFINE_TYPES would expose
>>>>>> some even if it's better than no macro at all.
>>>>>>
>>>>>> What exactly are the parameters missing from DEFINE_MACHINE_EXTENDED that
>>>>>> need to be added?
>>>>>
>>>>> Hi BALATON
>>>>> the things we faced is we first is to add TypeInfo::is_available parameter to
>>>>> DEFINE_MACHINE_EXTENDED, and have more usage of it.
>>>>> Then we will add targets:uint64_t parameter to DEFINE_MACHINE_EXTENDED, this is
>>>>> a prepare to remove TypeInfo::is_available parameter from
>>>>> DEFINE_MACHINE_EXTENDED,
>>>>>
>>>>> And finally, once all usage of TypeInfo::is_available can be replaced with
>>>>> targets:uint64_t, then we finally need to remove
>>>>> TypeInfo::is_available parameter from DEFINE_MACHINE_EXTENDED,
>>>>
>>>> Is there a way to avoid the temporary is_available churn and introduce the
>>>> targets:uint64_t right away? (I'm not following this so I don't really
>>>> know what you're talking about just looks like there's some churn here
>>>> which might be good to awoid anyway independent of these macros.)
>>>>
>>>>> That's what I am facing now. And the explicit
>>>>> static const TypeInfo xxx_machine_typeinfo = {
>>>>>    .name       = MACHINE_TYPE_NAME("xxx"),
>>>>>    .parent     = TYPE_MACHINE,
>>>>>    .class_init = xxx_machine_class_init,
>>>>> };
>>>>>
>>>>> Will help me avoid the issue. And I think this is a little boilerplate
>>>>> and very explicit.
>>>>
>>>> That's not all DEFINE_MACHINE hides though. It's longer with .abstract,
>>>> .secure and .iterfaces plus the machine initfn that would also need to be
>>>> expanded if you used DEFINE_TYPES.
>>>>
>>>> Is this conversion needed for all machines using all DEFINE_MACHINE
>>>
>>> At the end, only "none" machine do not have targets parameter or
>>> (QEMU_ARCH_ALL), as that's the sole
>>> machine that supports all targets.
>>>
>>>> variants or only some of them? If the latter why not convert those to
>>>
>>>
>>>
>>>
>>>> DEFINE_MACHINE_EXTENDED and then only that macro needs to be changed with
>>>> other wrappers passing a default value without needing a new parameter.
>>>> That does not work if all machines need to do this but even then, keeping
>>>> the macro and adding a new required parameter is better in my opinion as
>>>> it keeps boiler plate hidden.
>>>
>>> Another option is keep DEFINE_MACHINE and introduce DEFINE_MACHINE_TARGETS
>>> and remove DEFINE_MACHINE_EXTENDED, and we only use DEFINE_MACHINE for
>>> simple case,
>>> that is parent is TYPE_MACHINE and have no custom type and no more
>>> attributes assigned.
>>> DEFINE_MACHINE_EXTENDED is too verbose, when calling it, it less clear
>>> than calling to DEFINE_MACHINE.
>>> And if we want to set more attributes to TypeInfo, just expand it to
>>> use type_init or DEFINE_TYPES, how about this way.
>>>
>>> This will be something like:
>>>
>>> #define DEFINE_MACHINE_TARGETS(namestr, machine_initfn, targets) \
>>>    static void machine_initfn##_class_init(ObjectClass *oc, const void *data) \
>>>    { \
>>>        MachineClass *mc = MACHINE_CLASS(oc); \
>>>        machine_initfn(mc); \
>>>    } \
>>>    static const TypeInfo machine_initfn##_typeinfo = { \
>>>        .name       = MACHINE_TYPE_NAME(namestr), \
>>>        .parent     = TYPE_MACHINE, \
>>>        .class_init = machine_initfn##_class_init, \
>>>    }; \
>>>    static void machine_initfn##_register_types(void) \
>>>    { \
>>>        type_register_targets(&machine_initfn##_typeinfo, targets); \
>>>    } \
>>>    type_init(machine_initfn##_register_types)
>>>
>>> /* Implicitly insecure */
>>> #define DEFINE_MACHINE(namestr, machine_initfn) \
>>>    DEFINE_MACHINE_TARGETS(namestr, machine_initfn, QEMU_ARCH_ALL) \
>>>
>>> As the many call is to DEFINE_MACHINE.
>>>
>>> And after all conversion, all existing usage of DEFINE_MACHINE will be
>>> converted to
>>> DEFINE_MACHINE_TARGETS.
>>> DEFINE_MACHINE will be called for ('none') machine or future heterogeneous
>>> machines
>>>
>>>
>>> Either way, these patches will be dropped. We will introduce
>>> DEFINE_MACHINE_TARGETS first.
>>
>> I think I'm lost and cannot follow what you want. As far as I understood
>> you want to add a new field "target" to machine TypeInfo but instead of
>> adding that straight away you proposed to first add is_available then
>> later replace that with target. I asked why do you need is_available and
>> not add target right away?
>>
>> Then if this target parameter will be needed for all machines why can't
>> you add that to all DEFINE_MACHINE macros as a required parameter and set
>> it for all machines passing it through to DEFINE_MACHINE_EXTENDED which
>> sets in the TypeInfo. That way no machines need changing other than adding
>> the target parameter to the existing DEFINE_MACHINE calls.
>>
>> What am I missing?
> Or sorry, I did not explain well.
>
> I means reshape DEFINE_MACHINE like
>
> https://lore.kernel.org/qemu-devel/20261102194826.1298-1-luoyonggang@gmail.com/T/#u
>
> basically every call to DEFINE_MACHINE needs the targets parameter.
> So we can always passing targets parameter for DEFINE_MACHINE.

That's OK and is what I suggested, the part I did not get is why do you 
need an intermediate is_available step instead of just adding the target 
parameter to all DEFINE_MACHINE* macros.

> And I think we can remove DEFINE_MACHINE_EXTENDED, as the call to it is verbose

You can't (without bringing back boiler plate) because some machines need 
finer control. That's why we have DEFINE_MACHINE_EXTENDED with all 
possible parameters and convenience wrappers around it for simpler cases. 
It may be possible to reorganise the macros dropping some unused 
DEFINE_MACHINE variants and introducing new ones that better suit the 
needs of machines currently using DEFINE_MACHINE_EXTENDED but just 
expanding all boiler plate for more complex machines not using 
DEFINE_MACHINE is what I'd like to avoid.

Regards,
BALATON Zoltan

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 11175 bytes --]

On Tue, 3 Nov 2026, BALATON Zoltan wrote:
> On Tue, 3 Nov 2026, Yonggang Luo wrote:
>> On Mon, Nov 2, 2026 at 10:56 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>> 
>>> On Mon, 2 Nov 2026, Yonggang Luo wrote:
>>>> On Mon, Nov 2, 2026 at 4:57 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>> 
>>>>> On Sun, 1 Nov 2026, Yonggang Luo wrote:
>>>>>> On Sun, Nov 1, 2026 at 7:29 AM BALATON Zoltan <balaton@eik.bme.hu> 
>>>>>> wrote:
>>>>>>> 
>>>>>>> On Sun, 1 Nov 2026, Yonggang Luo wrote:
>>>>>>>> On Sun, Nov 1, 2026 at 1:06 AM BALATON Zoltan <balaton@eik.bme.hu> 
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> On Sat, 31 Oct 2026, Yonggang Luo wrote:
>>>>>>>>>> On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan <balaton@eik.bme.hu> 
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
>>>>>>>>>>>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
>>>>>>>>>>>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
>>>>>>>>>>>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo 
>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>> type_init
>>>>>>>>>>>>>> function that calls type_register_static(). A later change 
>>>>>>>>>>>>>> needs to
>>>>>>>>>>>>>> pass a
>>>>>>>>>>>>> 
>>>>>>>>>>>>> That's the point of the macro to hide the boiler plate code.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> target mask into that registration, and the macros have no 
>>>>>>>>>>>>>> parameter
>>>>>>>>>>>>>> for it.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Couldn't you just change the macros to take that parameter 
>>>>>>>>>>>>> instead of
>>>>>>>>>>>>> expanding it everywhere?
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Problem of macros is that they don't have default parameters, so 
>>>>>>>>>>>> you
>>>>>>>>>>>> need variants for everything:
>>>>>>>>>>>> 
>>>>>>>>>>>> DEFINE_MACHINE
>>>>>>>>>>>> DEFINE_MACHINE_EXTENDED
>>>>>>>>>>>> DEFINE_MACHINE_WITH_INTERFACES
>>>>>>>>>>>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
>>>>>>>>>>>> and now would need a new variant, with variant for other existing 
>>>>>>>>>>>> ones.
>>>>>>>>>>>> 
>>>>>>>>>>>> In the end, it's just simpler to remove this and add the 
>>>>>>>>>>>> boilerplate.
>>>>>>>>>>>> It's written once and never modified, so using a macro just save 
>>>>>>>>>>>> typing
>>>>>>>>>>>> those lines once.
>>>>>>>>>>>> 
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> BALATON Zoltan
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> This series expands every caller first, with no behavior 
>>>>>>>>>>>>>> change, so the
>>>>>>>>>>>>>> follow-up only replaces the type_register_static() call.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Each machine file gains a class_init function, a TypeInfo, and 
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> type_init
>>>>>>>>>>>>>> function that calls type_register_static(). The last patch 
>>>>>>>>>>>>>> removes
>>>>>>>>>>>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from 
>>>>>>>>>>>>>> include/hw/core/boards.h.
>>>>>>>>>>> 
>>>>>>>>>>> Macros help reading the code not saving typing. If the actual
>>>>>>>>>>> functionality is buried in a lot of boiler plate it's harder to 
>>>>>>>>>>> understand
>>>>>>>>>>> and spot bugs so putting the unintresting boiler plate behind a 
>>>>>>>>>>> macro is
>>>>>>>>>>> better even if you need a separate version for different cases. 
>>>>>>>>>>> Then the
>>>>>>>>>>> code that uses the macro will be much more obvious and not just a 
>>>>>>>>>>> lot of
>>>>>>>>>> 
>>>>>>>>>> I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* 
>>>>>>>>>> are
>>>>>>>>>> not defined properly
>>>>>>>>>> that causes them to not be extended easily.
>>>>>>>>>> 
>>>>>>>>>> DEFINE_TYPES is another example, use them can extend easily, how 
>>>>>>>>>> about
>>>>>>>>>> always use DEFINE_TYPES?
>>>>>>>>>> Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and 
>>>>>>>>>> DEFINE_SECURE_MACHINE*?
>>>>>>>>> 
>>>>>>>>> Maybe I'm missing the problem but DEFINE_MACHINE macros are just
>>>>>>>>> convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't 
>>>>>>>>> you add
>>>>>>>>> the needed parameter to DEFINE_MACHINE_EXTENDED and use that for 
>>>>>>>>> machines
>>>>>>>>> that need it, or if it's needed by all machines then make the new
>>>>>>>>> parameter required and add it to all convenience wrappers too so you 
>>>>>>>>> can
>>>>>>>>> keep using DEFINE_MACHINE* and just need to add one parameter to it 
>>>>>>>>> in
>>>>>>>>> machines?
>>>>>>>> 
>>>>>>>> That's the issue, add parameter to DEFINE_MACHINE_EXTENDED means all
>>>>>>>> calls to it also need
>>>>>>>> to be changed, that means touch many $target_arch files. currently
>>>>>>>> it's 13. But after these
>>>>>>> 
>>>>>>> That's not different from expanding the macro which would touch the 
>>>>>>> same
>>>>>>> files.
>>>>>>> 
>>>>>>>> changes, there will be much more usage on it, and if we want to add
>>>>>>>> more parameters or attributes
>>>>>>>> to it, it will be a new tree-wide change.
>>>>>>> 
>>>>>>> Do you expect to need more parameters? Can't you add them at once 
>>>>>>> then?
>>>>>>> 
>>>>>>>> And DEFINE_TYPES do not suffer from such issues. As the TypeInfo[] is
>>>>>>>> explicit defined for
>>>>>>>> DEFINE_TYPES
>>>>>>> 
>>>>>>> My point is that keeping the boiler plate as little as possible makes 
>>>>>>> the
>>>>>>> code more readable. DEFINE_TYPES hides some of the boiler plate,
>>>>>>> DEFINE_MACHINE hides even more so converting to DEFINE_TYPES would 
>>>>>>> expose
>>>>>>> some even if it's better than no macro at all.
>>>>>>> 
>>>>>>> What exactly are the parameters missing from DEFINE_MACHINE_EXTENDED 
>>>>>>> that
>>>>>>> need to be added?
>>>>>> 
>>>>>> Hi BALATON
>>>>>> the things we faced is we first is to add TypeInfo::is_available 
>>>>>> parameter to
>>>>>> DEFINE_MACHINE_EXTENDED, and have more usage of it.
>>>>>> Then we will add targets:uint64_t parameter to DEFINE_MACHINE_EXTENDED, 
>>>>>> this is
>>>>>> a prepare to remove TypeInfo::is_available parameter from
>>>>>> DEFINE_MACHINE_EXTENDED,
>>>>>> 
>>>>>> And finally, once all usage of TypeInfo::is_available can be replaced 
>>>>>> with
>>>>>> targets:uint64_t, then we finally need to remove
>>>>>> TypeInfo::is_available parameter from DEFINE_MACHINE_EXTENDED,
>>>>> 
>>>>> Is there a way to avoid the temporary is_available churn and introduce 
>>>>> the
>>>>> targets:uint64_t right away? (I'm not following this so I don't really
>>>>> know what you're talking about just looks like there's some churn here
>>>>> which might be good to awoid anyway independent of these macros.)
>>>>> 
>>>>>> That's what I am facing now. And the explicit
>>>>>> static const TypeInfo xxx_machine_typeinfo = {
>>>>>>    .name       = MACHINE_TYPE_NAME("xxx"),
>>>>>>    .parent     = TYPE_MACHINE,
>>>>>>    .class_init = xxx_machine_class_init,
>>>>>> };
>>>>>> 
>>>>>> Will help me avoid the issue. And I think this is a little boilerplate
>>>>>> and very explicit.
>>>>> 
>>>>> That's not all DEFINE_MACHINE hides though. It's longer with .abstract,
>>>>> .secure and .iterfaces plus the machine initfn that would also need to 
>>>>> be
>>>>> expanded if you used DEFINE_TYPES.
>>>>> 
>>>>> Is this conversion needed for all machines using all DEFINE_MACHINE
>>>> 
>>>> At the end, only "none" machine do not have targets parameter or
>>>> (QEMU_ARCH_ALL), as that's the sole
>>>> machine that supports all targets.
>>>> 
>>>>> variants or only some of them? If the latter why not convert those to
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> DEFINE_MACHINE_EXTENDED and then only that macro needs to be changed 
>>>>> with
>>>>> other wrappers passing a default value without needing a new parameter.
>>>>> That does not work if all machines need to do this but even then, 
>>>>> keeping
>>>>> the macro and adding a new required parameter is better in my opinion as
>>>>> it keeps boiler plate hidden.
>>>> 
>>>> Another option is keep DEFINE_MACHINE and introduce 
>>>> DEFINE_MACHINE_TARGETS
>>>> and remove DEFINE_MACHINE_EXTENDED, and we only use DEFINE_MACHINE for
>>>> simple case,
>>>> that is parent is TYPE_MACHINE and have no custom type and no more
>>>> attributes assigned.
>>>> DEFINE_MACHINE_EXTENDED is too verbose, when calling it, it less clear
>>>> than calling to DEFINE_MACHINE.
>>>> And if we want to set more attributes to TypeInfo, just expand it to
>>>> use type_init or DEFINE_TYPES, how about this way.
>>>> 
>>>> This will be something like:
>>>> 
>>>> #define DEFINE_MACHINE_TARGETS(namestr, machine_initfn, targets) \
>>>>    static void machine_initfn##_class_init(ObjectClass *oc, const void 
>>>> *data) \
>>>>    { \
>>>>        MachineClass *mc = MACHINE_CLASS(oc); \
>>>>        machine_initfn(mc); \
>>>>    } \
>>>>    static const TypeInfo machine_initfn##_typeinfo = { \
>>>>        .name       = MACHINE_TYPE_NAME(namestr), \
>>>>        .parent     = TYPE_MACHINE, \
>>>>        .class_init = machine_initfn##_class_init, \
>>>>    }; \
>>>>    static void machine_initfn##_register_types(void) \
>>>>    { \
>>>>        type_register_targets(&machine_initfn##_typeinfo, targets); \
>>>>    } \
>>>>    type_init(machine_initfn##_register_types)
>>>> 
>>>> /* Implicitly insecure */
>>>> #define DEFINE_MACHINE(namestr, machine_initfn) \
>>>>    DEFINE_MACHINE_TARGETS(namestr, machine_initfn, QEMU_ARCH_ALL) \
>>>> 
>>>> As the many call is to DEFINE_MACHINE.
>>>> 
>>>> And after all conversion, all existing usage of DEFINE_MACHINE will be
>>>> converted to
>>>> DEFINE_MACHINE_TARGETS.
>>>> DEFINE_MACHINE will be called for ('none') machine or future 
>>>> heterogeneous
>>>> machines
>>>> 
>>>> 
>>>> Either way, these patches will be dropped. We will introduce
>>>> DEFINE_MACHINE_TARGETS first.
>>> 
>>> I think I'm lost and cannot follow what you want. As far as I understood
>>> you want to add a new field "target" to machine TypeInfo but instead of
>>> adding that straight away you proposed to first add is_available then
>>> later replace that with target. I asked why do you need is_available and
>>> not add target right away?
>>> 
>>> Then if this target parameter will be needed for all machines why can't
>>> you add that to all DEFINE_MACHINE macros as a required parameter and set
>>> it for all machines passing it through to DEFINE_MACHINE_EXTENDED which
>>> sets in the TypeInfo. That way no machines need changing other than adding
>>> the target parameter to the existing DEFINE_MACHINE calls.
>>> 
>>> What am I missing?
>> Or sorry, I did not explain well.
>> 
>> I means reshape DEFINE_MACHINE like
>> 
>> https://lore.kernel.org/qemu-devel/20261102194826.1298-1-luoyonggang@gmail.com/T/#u
>> 
>> basically every call to DEFINE_MACHINE needs the targets parameter.
>> So we can always passing targets parameter for DEFINE_MACHINE.
>
> That's OK and is what I suggested, the part I did not get is why do you need 
> an intermediate is_available step instead of just adding the target parameter 
> to all DEFINE_MACHINE* macros.

I noticed there's some redundancy between the arch and the name prefix 
with this change. Basically you're trying to split namestr into name and 
arch where the final machine name will be arch-name. Is there a way to do 
this from the macro somehow so you don't have to specify the arch twice 
once in the name and once as an enum?

Regards,
BALATON Zoltan

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

On Tue, Nov 3, 2026 at 9:26 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Tue, 3 Nov 2026, BALATON Zoltan wrote:
> > On Tue, 3 Nov 2026, Yonggang Luo wrote:
> >> On Mon, Nov 2, 2026 at 10:56 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>>
> >>> On Mon, 2 Nov 2026, Yonggang Luo wrote:
> >>>> On Mon, Nov 2, 2026 at 4:57 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>>>>
> >>>>> On Sun, 1 Nov 2026, Yonggang Luo wrote:
> >>>>>> On Sun, Nov 1, 2026 at 7:29 AM BALATON Zoltan <balaton@eik.bme.hu>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Sun, 1 Nov 2026, Yonggang Luo wrote:
> >>>>>>>> On Sun, Nov 1, 2026 at 1:06 AM BALATON Zoltan <balaton@eik.bme.hu>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> On Sat, 31 Oct 2026, Yonggang Luo wrote:
> >>>>>>>>>> On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan <balaton@eik.bme.hu>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
> >>>>>>>>>>>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> >>>>>>>>>>>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
> >>>>>>>>>>>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo
> >>>>>>>>>>>>>> and the
> >>>>>>>>>>>>>> type_init
> >>>>>>>>>>>>>> function that calls type_register_static(). A later change
> >>>>>>>>>>>>>> needs to
> >>>>>>>>>>>>>> pass a
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That's the point of the macro to hide the boiler plate code.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> target mask into that registration, and the macros have no
> >>>>>>>>>>>>>> parameter
> >>>>>>>>>>>>>> for it.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Couldn't you just change the macros to take that parameter
> >>>>>>>>>>>>> instead of
> >>>>>>>>>>>>> expanding it everywhere?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Problem of macros is that they don't have default parameters, so
> >>>>>>>>>>>> you
> >>>>>>>>>>>> need variants for everything:
> >>>>>>>>>>>>
> >>>>>>>>>>>> DEFINE_MACHINE
> >>>>>>>>>>>> DEFINE_MACHINE_EXTENDED
> >>>>>>>>>>>> DEFINE_MACHINE_WITH_INTERFACES
> >>>>>>>>>>>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> >>>>>>>>>>>> and now would need a new variant, with variant for other existing
> >>>>>>>>>>>> ones.
> >>>>>>>>>>>>
> >>>>>>>>>>>> In the end, it's just simpler to remove this and add the
> >>>>>>>>>>>> boilerplate.
> >>>>>>>>>>>> It's written once and never modified, so using a macro just save
> >>>>>>>>>>>> typing
> >>>>>>>>>>>> those lines once.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>> BALATON Zoltan
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> This series expands every caller first, with no behavior
> >>>>>>>>>>>>>> change, so the
> >>>>>>>>>>>>>> follow-up only replaces the type_register_static() call.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Each machine file gains a class_init function, a TypeInfo, and
> >>>>>>>>>>>>>> a
> >>>>>>>>>>>>>> type_init
> >>>>>>>>>>>>>> function that calls type_register_static(). The last patch
> >>>>>>>>>>>>>> removes
> >>>>>>>>>>>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from
> >>>>>>>>>>>>>> include/hw/core/boards.h.
> >>>>>>>>>>>
> >>>>>>>>>>> Macros help reading the code not saving typing. If the actual
> >>>>>>>>>>> functionality is buried in a lot of boiler plate it's harder to
> >>>>>>>>>>> understand
> >>>>>>>>>>> and spot bugs so putting the unintresting boiler plate behind a
> >>>>>>>>>>> macro is
> >>>>>>>>>>> better even if you need a separate version for different cases.
> >>>>>>>>>>> Then the
> >>>>>>>>>>> code that uses the macro will be much more obvious and not just a
> >>>>>>>>>>> lot of
> >>>>>>>>>>
> >>>>>>>>>> I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*
> >>>>>>>>>> are
> >>>>>>>>>> not defined properly
> >>>>>>>>>> that causes them to not be extended easily.
> >>>>>>>>>>
> >>>>>>>>>> DEFINE_TYPES is another example, use them can extend easily, how
> >>>>>>>>>> about
> >>>>>>>>>> always use DEFINE_TYPES?
> >>>>>>>>>> Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and
> >>>>>>>>>> DEFINE_SECURE_MACHINE*?
> >>>>>>>>>
> >>>>>>>>> Maybe I'm missing the problem but DEFINE_MACHINE macros are just
> >>>>>>>>> convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't
> >>>>>>>>> you add
> >>>>>>>>> the needed parameter to DEFINE_MACHINE_EXTENDED and use that for
> >>>>>>>>> machines
> >>>>>>>>> that need it, or if it's needed by all machines then make the new
> >>>>>>>>> parameter required and add it to all convenience wrappers too so you
> >>>>>>>>> can
> >>>>>>>>> keep using DEFINE_MACHINE* and just need to add one parameter to it
> >>>>>>>>> in
> >>>>>>>>> machines?
> >>>>>>>>
> >>>>>>>> That's the issue, add parameter to DEFINE_MACHINE_EXTENDED means all
> >>>>>>>> calls to it also need
> >>>>>>>> to be changed, that means touch many $target_arch files. currently
> >>>>>>>> it's 13. But after these
> >>>>>>>
> >>>>>>> That's not different from expanding the macro which would touch the
> >>>>>>> same
> >>>>>>> files.
> >>>>>>>
> >>>>>>>> changes, there will be much more usage on it, and if we want to add
> >>>>>>>> more parameters or attributes
> >>>>>>>> to it, it will be a new tree-wide change.
> >>>>>>>
> >>>>>>> Do you expect to need more parameters? Can't you add them at once
> >>>>>>> then?
> >>>>>>>
> >>>>>>>> And DEFINE_TYPES do not suffer from such issues. As the TypeInfo[] is
> >>>>>>>> explicit defined for
> >>>>>>>> DEFINE_TYPES
> >>>>>>>
> >>>>>>> My point is that keeping the boiler plate as little as possible makes
> >>>>>>> the
> >>>>>>> code more readable. DEFINE_TYPES hides some of the boiler plate,
> >>>>>>> DEFINE_MACHINE hides even more so converting to DEFINE_TYPES would
> >>>>>>> expose
> >>>>>>> some even if it's better than no macro at all.
> >>>>>>>
> >>>>>>> What exactly are the parameters missing from DEFINE_MACHINE_EXTENDED
> >>>>>>> that
> >>>>>>> need to be added?
> >>>>>>
> >>>>>> Hi BALATON
> >>>>>> the things we faced is we first is to add TypeInfo::is_available
> >>>>>> parameter to
> >>>>>> DEFINE_MACHINE_EXTENDED, and have more usage of it.
> >>>>>> Then we will add targets:uint64_t parameter to DEFINE_MACHINE_EXTENDED,
> >>>>>> this is
> >>>>>> a prepare to remove TypeInfo::is_available parameter from
> >>>>>> DEFINE_MACHINE_EXTENDED,
> >>>>>>
> >>>>>> And finally, once all usage of TypeInfo::is_available can be replaced
> >>>>>> with
> >>>>>> targets:uint64_t, then we finally need to remove
> >>>>>> TypeInfo::is_available parameter from DEFINE_MACHINE_EXTENDED,
> >>>>>
> >>>>> Is there a way to avoid the temporary is_available churn and introduce
> >>>>> the
> >>>>> targets:uint64_t right away? (I'm not following this so I don't really
> >>>>> know what you're talking about just looks like there's some churn here
> >>>>> which might be good to awoid anyway independent of these macros.)
> >>>>>
> >>>>>> That's what I am facing now. And the explicit
> >>>>>> static const TypeInfo xxx_machine_typeinfo = {
> >>>>>>    .name       = MACHINE_TYPE_NAME("xxx"),
> >>>>>>    .parent     = TYPE_MACHINE,
> >>>>>>    .class_init = xxx_machine_class_init,
> >>>>>> };
> >>>>>>
> >>>>>> Will help me avoid the issue. And I think this is a little boilerplate
> >>>>>> and very explicit.
> >>>>>
> >>>>> That's not all DEFINE_MACHINE hides though. It's longer with .abstract,
> >>>>> .secure and .iterfaces plus the machine initfn that would also need to
> >>>>> be
> >>>>> expanded if you used DEFINE_TYPES.
> >>>>>
> >>>>> Is this conversion needed for all machines using all DEFINE_MACHINE
> >>>>
> >>>> At the end, only "none" machine do not have targets parameter or
> >>>> (QEMU_ARCH_ALL), as that's the sole
> >>>> machine that supports all targets.
> >>>>
> >>>>> variants or only some of them? If the latter why not convert those to
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> DEFINE_MACHINE_EXTENDED and then only that macro needs to be changed
> >>>>> with
> >>>>> other wrappers passing a default value without needing a new parameter.
> >>>>> That does not work if all machines need to do this but even then,
> >>>>> keeping
> >>>>> the macro and adding a new required parameter is better in my opinion as
> >>>>> it keeps boiler plate hidden.
> >>>>
> >>>> Another option is keep DEFINE_MACHINE and introduce
> >>>> DEFINE_MACHINE_TARGETS
> >>>> and remove DEFINE_MACHINE_EXTENDED, and we only use DEFINE_MACHINE for
> >>>> simple case,
> >>>> that is parent is TYPE_MACHINE and have no custom type and no more
> >>>> attributes assigned.
> >>>> DEFINE_MACHINE_EXTENDED is too verbose, when calling it, it less clear
> >>>> than calling to DEFINE_MACHINE.
> >>>> And if we want to set more attributes to TypeInfo, just expand it to
> >>>> use type_init or DEFINE_TYPES, how about this way.
> >>>>
> >>>> This will be something like:
> >>>>
> >>>> #define DEFINE_MACHINE_TARGETS(namestr, machine_initfn, targets) \
> >>>>    static void machine_initfn##_class_init(ObjectClass *oc, const void
> >>>> *data) \
> >>>>    { \
> >>>>        MachineClass *mc = MACHINE_CLASS(oc); \
> >>>>        machine_initfn(mc); \
> >>>>    } \
> >>>>    static const TypeInfo machine_initfn##_typeinfo = { \
> >>>>        .name       = MACHINE_TYPE_NAME(namestr), \
> >>>>        .parent     = TYPE_MACHINE, \
> >>>>        .class_init = machine_initfn##_class_init, \
> >>>>    }; \
> >>>>    static void machine_initfn##_register_types(void) \
> >>>>    { \
> >>>>        type_register_targets(&machine_initfn##_typeinfo, targets); \
> >>>>    } \
> >>>>    type_init(machine_initfn##_register_types)
> >>>>
> >>>> /* Implicitly insecure */
> >>>> #define DEFINE_MACHINE(namestr, machine_initfn) \
> >>>>    DEFINE_MACHINE_TARGETS(namestr, machine_initfn, QEMU_ARCH_ALL) \
> >>>>
> >>>> As the many call is to DEFINE_MACHINE.
> >>>>
> >>>> And after all conversion, all existing usage of DEFINE_MACHINE will be
> >>>> converted to
> >>>> DEFINE_MACHINE_TARGETS.
> >>>> DEFINE_MACHINE will be called for ('none') machine or future
> >>>> heterogeneous
> >>>> machines
> >>>>
> >>>>
> >>>> Either way, these patches will be dropped. We will introduce
> >>>> DEFINE_MACHINE_TARGETS first.
> >>>
> >>> I think I'm lost and cannot follow what you want. As far as I understood
> >>> you want to add a new field "target" to machine TypeInfo but instead of
> >>> adding that straight away you proposed to first add is_available then
> >>> later replace that with target. I asked why do you need is_available and
> >>> not add target right away?
> >>>
> >>> Then if this target parameter will be needed for all machines why can't
> >>> you add that to all DEFINE_MACHINE macros as a required parameter and set
> >>> it for all machines passing it through to DEFINE_MACHINE_EXTENDED which
> >>> sets in the TypeInfo. That way no machines need changing other than adding
> >>> the target parameter to the existing DEFINE_MACHINE calls.
> >>>
> >>> What am I missing?
> >> Or sorry, I did not explain well.
> >>
> >> I means reshape DEFINE_MACHINE like
> >>
> >> https://lore.kernel.org/qemu-devel/20261102194826.1298-1-luoyonggang@gmail.com/T/#u
> >>
> >> basically every call to DEFINE_MACHINE needs the targets parameter.
> >> So we can always passing targets parameter for DEFINE_MACHINE.
> >
> > That's OK and is what I suggested, the part I did not get is why do you need
> > an intermediate is_available step instead of just adding the target parameter
> > to all DEFINE_MACHINE* macros.
>
> I noticed there's some redundancy between the arch and the name prefix
> with this change. Basically you're trying to split namestr into name and
> arch where the final machine name will be arch-name. Is there a way to do
> this from the macro somehow so you don't have to specify the arch twice
> once in the name and once as an enum?

There won't be redundancy, the change's intention is to keep the
machine QOM-name not
changed, specifically, drop MR
https://lore.kernel.org/qemu-devel/20261027111216.392-1-luoyonggang@gmail.com/
so we can keep the QOM name for machines not changed by introduce a
extra targets parameter
to it, then we can use buckets to storage different arch/target, I've
already implemented
that at https://gitlab.com/lygstate-qemu/qemu/-/commits/qom-type-buckets?ref_type=heads,
 and it's working well:)

I am trying to get it merged by sending smaller patches.

Basically we always need a "targets" parameter or
"TargetInfo::is_avaiable" attributes.
the targets parameter will be saved into TargetImpl::targets, and not
in TargetInfo, as the default
value for TargetInfo is 0, means no targets. but we want keep
"QEMU_ARCH_ALL" default behavior, that's why
I want it to be a parameter, not a TargetInfo member

>
> Regards,
> BALATON Zoltan



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

On Mon, Nov 2, 2026 at 4:57 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
>
> Is this conversion needed for all machines using all DEFINE_MACHINE
> variants or only some of them? If the latter why not convert those to

The is_avaiable add/remove no need all machines, only a small number of machines
need touch DEFINE_MACHINE, I'll do(expand) them when needed.

-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

On Sun, Nov 1, 2026 at 7:29 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Sun, 1 Nov 2026, Yonggang Luo wrote:
> > On Sun, Nov 1, 2026 at 1:06 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>
> >> On Sat, 31 Oct 2026, Yonggang Luo wrote:
> >>> On Sat, Oct 31, 2026 at 8:42 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >>>>
> >>>> On Fri, 30 Oct 2026, Pierrick Bouvier wrote:
> >>>>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> >>>>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
> >>>>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
> >>>>>>> type_init
> >>>>>>> function that calls type_register_static(). A later change needs to
> >>>>>>> pass a
> >>>>>>
> >>>>>> That's the point of the macro to hide the boiler plate code.
> >>>>>>
> >>>>>>> target mask into that registration, and the macros have no parameter
> >>>>>>> for it.
> >>>>>>
> >>>>>> Couldn't you just change the macros to take that parameter instead of
> >>>>>> expanding it everywhere?
> >>>>>>
> >>>>>
> >>>>> Problem of macros is that they don't have default parameters, so you
> >>>>> need variants for everything:
> >>>>>
> >>>>> DEFINE_MACHINE
> >>>>> DEFINE_MACHINE_EXTENDED
> >>>>> DEFINE_MACHINE_WITH_INTERFACES
> >>>>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> >>>>> and now would need a new variant, with variant for other existing ones.
> >>>>>
> >>>>> In the end, it's just simpler to remove this and add the boilerplate.
> >>>>> It's written once and never modified, so using a macro just save typing
> >>>>> those lines once.
> >>>>>
> >>>>>> Regards,
> >>>>>> BALATON Zoltan
> >>>>>>
> >>>>>>> This series expands every caller first, with no behavior change, so the
> >>>>>>> follow-up only replaces the type_register_static() call.
> >>>>>>>
> >>>>>>> Each machine file gains a class_init function, a TypeInfo, and a
> >>>>>>> type_init
> >>>>>>> function that calls type_register_static(). The last patch removes
> >>>>>>> DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* from include/hw/core/boards.h.
> >>>>
> >>>> Macros help reading the code not saving typing. If the actual
> >>>> functionality is buried in a lot of boiler plate it's harder to understand
> >>>> and spot bugs so putting the unintresting boiler plate behind a macro is
> >>>> better even if you need a separate version for different cases. Then the
> >>>> code that uses the macro will be much more obvious and not just a lot of
> >>>
> >>> I think mainly because DEFINE_MACHINE* and DEFINE_SECURE_MACHINE* are
> >>> not defined properly
> >>> that causes them to not be extended easily.
> >>>
> >>> DEFINE_TYPES is another example, use them can extend easily, how about
> >>> always use DEFINE_TYPES?
> >>> Or add a DEFINE_TYPE to replace DEFINE_MACHINE* and DEFINE_SECURE_MACHINE*?
> >>
> >> Maybe I'm missing the problem but DEFINE_MACHINE macros are just
> >> convenience wrappers around DEFINE_MACHINE_EXTENDED. So why can't you add
> >> the needed parameter to DEFINE_MACHINE_EXTENDED and use that for machines
> >> that need it, or if it's needed by all machines then make the new
> >> parameter required and add it to all convenience wrappers too so you can
> >> keep using DEFINE_MACHINE* and just need to add one parameter to it in
> >> machines?
> >
> > That's the issue, add parameter to DEFINE_MACHINE_EXTENDED means all
> > calls to it also need
> > to be changed, that means touch many $target_arch files. currently
> > it's 13. But after these
>
> That's not different from expanding the macro which would touch the same
> files.
>
> > changes, there will be much more usage on it, and if we want to add
> > more parameters or attributes
> > to it, it will be a new tree-wide change.
>
> Do you expect to need more parameters? Can't you add them at once then?
>
> > And DEFINE_TYPES do not suffer from such issues. As the TypeInfo[] is
> > explicit defined for
> > DEFINE_TYPES
>
> My point is that keeping the boiler plate as little as possible makes the
This is also what I want, makes the code more readable and little boiler plate.
> code more readable. DEFINE_TYPES hides some of the boiler plate,

The DEFINE_TYPES would be like this:

static const TypeInfo dp264_types[] = {
    {
        .name       = MACHINE_TYPE_NAME("clipper"),
        .parent     = TYPE_MACHINE,
        .class_init = clipper_machine_class_init,
    },
};

DEFINE_TYPES(dp264_types)


> DEFINE_MACHINE hides even more so converting to DEFINE_TYPES would expose
> some even if it's better than no macro at all.
>
> What exactly are the parameters missing from DEFINE_MACHINE_EXTENDED that
> need to be added?
>
> Regards,
> BALATON Zoltan



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Daniel P. Berrangé]

On Fri, Oct 30, 2026 at 05:51:44PM -0800, Pierrick Bouvier wrote:
> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> > On Fri, 30 Oct 2026, Yonggang Luo wrote:
> >> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
> >> type_init
> >> function that calls type_register_static(). A later change needs to
> >> pass a
> > 
> > That's the point of the macro to hide the boiler plate code.
> > 
> >> target mask into that registration, and the macros have no parameter
> >> for it.
> > 
> > Couldn't you just change the macros to take that parameter instead of
> > expanding it everywhere?
> >
> 
> Problem of macros is that they don't have default parameters, so you
> need variants for everything:
> 
> DEFINE_MACHINE
> DEFINE_MACHINE_EXTENDED
> DEFINE_MACHINE_WITH_INTERFACES
> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> and now would need a new variant, with variant for other existing ones.
> 
> In the end, it's just simpler to remove this and add the boilerplate.
> It's written once and never modified, so using a macro just save typing
> those lines once.

For each machine, it is only written once, but we add machines
over time, and every time a new machine is added the code style
is slightly different. We introduced all the variuos DEFINE_*
macros for QOM to better ensure consistent style and usage as
new code is added over time.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

On Tue, Nov 3, 2026 at 4:16 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Fri, Oct 30, 2026 at 05:51:44PM -0800, Pierrick Bouvier wrote:
> > On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> > > On Fri, 30 Oct 2026, Yonggang Luo wrote:
> > >> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
> > >> type_init
> > >> function that calls type_register_static(). A later change needs to
> > >> pass a
> > >
> > > That's the point of the macro to hide the boiler plate code.
> > >
> > >> target mask into that registration, and the macros have no parameter
> > >> for it.
> > >
> > > Couldn't you just change the macros to take that parameter instead of
> > > expanding it everywhere?
> > >
> >
> > Problem of macros is that they don't have default parameters, so you
> > need variants for everything:
> >
> > DEFINE_MACHINE
> > DEFINE_MACHINE_EXTENDED
> > DEFINE_MACHINE_WITH_INTERFACES
> > DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> > and now would need a new variant, with variant for other existing ones.
> >
> > In the end, it's just simpler to remove this and add the boilerplate.
> > It's written once and never modified, so using a macro just save typing
> > those lines once.
>
> For each machine, it is only written once, but we add machines
> over time, and every time a new machine is added the code style
> is slightly different. We introduced all the variuos DEFINE_*
> macros for QOM to better ensure consistent style and usage as
> new code is added over time.

I understand that the DEFINE_* macros are bloating because of this.
Indeed currently the only two macros used are "DEFINE_MACHINE" and
"DEFINE_MACHINE_EXTENDED"
; each time people want to add a new attribute, the macros is twiced.
And the usage of DEFINE_MACHINE_EXTENDED is rare and can be replaced
with DEFINE_TYPES or TypeInfo
and be more explicit. When we used as macro parameter, we need think
what's that parameter means, and for
TypeInfo, we can directly know what that member is about(because we
are assigned with the member name).
That's why I suggest keeping a single DEFINE_MACHINE, just like
DEFINE_TYPES; as they are the most
used macros(and simple enough), and won't suffer from changes much.

>
> With regards,
> Daniel
> --
> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|
>


-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 3811 bytes --]

On Tue, 3 Nov 2026, Yonggang Luo wrote:
> On Tue, Nov 3, 2026 at 4:16 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>>
>> On Fri, Oct 30, 2026 at 05:51:44PM -0800, Pierrick Bouvier wrote:
>>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
>>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
>>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
>>>>> type_init
>>>>> function that calls type_register_static(). A later change needs to
>>>>> pass a
>>>>
>>>> That's the point of the macro to hide the boiler plate code.
>>>>
>>>>> target mask into that registration, and the macros have no parameter
>>>>> for it.
>>>>
>>>> Couldn't you just change the macros to take that parameter instead of
>>>> expanding it everywhere?
>>>>
>>>
>>> Problem of macros is that they don't have default parameters, so you
>>> need variants for everything:
>>>
>>> DEFINE_MACHINE
>>> DEFINE_MACHINE_EXTENDED
>>> DEFINE_MACHINE_WITH_INTERFACES
>>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
>>> and now would need a new variant, with variant for other existing ones.
>>>
>>> In the end, it's just simpler to remove this and add the boilerplate.
>>> It's written once and never modified, so using a macro just save typing
>>> those lines once.
>>
>> For each machine, it is only written once, but we add machines
>> over time, and every time a new machine is added the code style
>> is slightly different. We introduced all the variuos DEFINE_*
>> macros for QOM to better ensure consistent style and usage as
>> new code is added over time.
>
> I understand that the DEFINE_* macros are bloating because of this.
> Indeed currently the only two macros used are "DEFINE_MACHINE" and
> "DEFINE_MACHINE_EXTENDED"

There are a few machines using some others but these are the most used. 
That suggests maybe we should change the convenience wrappers to match 
what machines need but DEFINE_MACHINE_EXTENDED is meant to be the one that 
allows all parameters which should be rarely needed.

> ; each time people want to add a new attribute, the macros is twiced.

Not necessarily. The SECURE parameter did that to preserve previous 
behaviour but if you add new parameter changing all callers (which is the 
same as expanding the macro that would also change all callers) then it's 
just a new parameter added not changing the number of DEFINE_MACHINE* 
wrappers. Rearranging the wrappers to make DEFINE_MACHINE_EXTENDED used 
less is an independent change.

> And the usage of DEFINE_MACHINE_EXTENDED is rare and can be replaced
> with DEFINE_TYPES or TypeInfo
> and be more explicit. When we used as macro parameter, we need think

But that defies the purpose of hiding the QOM boiler plate as much as 
possible. New people are confused by QOM and it's easier for them to look 
up documentation on the DEFINE_MACHINE* macros to see what parameter is 
what and not care about how it's stored in QOM TypeInfo or what is that 
at all.

> what's that parameter means, and for
> TypeInfo, we can directly know what that member is about(because we
> are assigned with the member name).

The parameter also has a name and documentation so it's not simpler to 
look up TypeInfo than look at the macro definition or docs. In fact it's 
harder to guess from TypeInfo as then you also need to get into QOM.

> That's why I suggest keeping a single DEFINE_MACHINE, just like
> DEFINE_TYPES; as they are the most
> used macros(and simple enough), and won't suffer from changes much.

That means exposing all the boiler plate for all machines other than the 
simplest case. I think it would be better to keep DEFINE_MACHINE_EXTENDED 
but maybe rethink the existing wrappers and drop unused ones and maybe add 
new ones that reduce the usage of DEFINE_MACHINE_EXTENDED but still keep 
the boiler plate hidden.

Regards,
BALATON Zoltan

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

On Tue, Nov 3, 2026 at 9:23 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Tue, 3 Nov 2026, Yonggang Luo wrote:
> > On Tue, Nov 3, 2026 at 4:16 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >>
> >> On Fri, Oct 30, 2026 at 05:51:44PM -0800, Pierrick Bouvier wrote:
> >>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> >>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
> >>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
> >>>>> type_init
> >>>>> function that calls type_register_static(). A later change needs to
> >>>>> pass a
> >>>>
> >>>> That's the point of the macro to hide the boiler plate code.
> >>>>
> >>>>> target mask into that registration, and the macros have no parameter
> >>>>> for it.
> >>>>
> >>>> Couldn't you just change the macros to take that parameter instead of
> >>>> expanding it everywhere?
> >>>>
> >>>
> >>> Problem of macros is that they don't have default parameters, so you
> >>> need variants for everything:
> >>>
> >>> DEFINE_MACHINE
> >>> DEFINE_MACHINE_EXTENDED
> >>> DEFINE_MACHINE_WITH_INTERFACES
> >>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> >>> and now would need a new variant, with variant for other existing ones.
> >>>
> >>> In the end, it's just simpler to remove this and add the boilerplate.
> >>> It's written once and never modified, so using a macro just save typing
> >>> those lines once.
> >>
> >> For each machine, it is only written once, but we add machines
> >> over time, and every time a new machine is added the code style
> >> is slightly different. We introduced all the variuos DEFINE_*
> >> macros for QOM to better ensure consistent style and usage as
> >> new code is added over time.
> >
> > I understand that the DEFINE_* macros are bloating because of this.
> > Indeed currently the only two macros used are "DEFINE_MACHINE" and
> > "DEFINE_MACHINE_EXTENDED"
>
> There are a few machines using some others but these are the most used.
> That suggests maybe we should change the convenience wrappers to match
> what machines need but DEFINE_MACHINE_EXTENDED is meant to be the one that
> allows all parameters which should be rarely needed.
>
> > ; each time people want to add a new attribute, the macros is twiced.
>
> Not necessarily. The SECURE parameter did that to preserve previous
> behaviour but if you add new parameter changing all callers (which is the
> same as expanding the macro that would also change all callers) then it's
> just a new parameter added not changing the number of DEFINE_MACHINE*
> wrappers. Rearranging the wrappers to make DEFINE_MACHINE_EXTENDED used
> less is an independent change.
>
> > And the usage of DEFINE_MACHINE_EXTENDED is rare and can be replaced
> > with DEFINE_TYPES or TypeInfo
> > and be more explicit. When we used as macro parameter, we need think
>
> But that defies the purpose of hiding the QOM boiler plate as much as
> possible. New people are confused by QOM and it's easier for them to look
> up documentation on the DEFINE_MACHINE* macros to see what parameter is
> what and not care about how it's stored in QOM TypeInfo or what is that
> at all.
>
> > what's that parameter means, and for
> > TypeInfo, we can directly know what that member is about(because we
> > are assigned with the member name).
>
> The parameter also has a name and documentation so it's not simpler to
> look up TypeInfo than look at the macro definition or docs. In fact it's
> harder to guess from TypeInfo as then you also need to get into QOM.
>
> > That's why I suggest keeping a single DEFINE_MACHINE, just like
> > DEFINE_TYPES; as they are the most
> > used macros(and simple enough), and won't suffer from changes much.
>
> That means exposing all the boiler plate for all machines other than the
> simplest case. I think it would be better to keep DEFINE_MACHINE_EXTENDED
> but maybe rethink the existing wrappers and drop unused ones and maybe add
> new ones that reduce the usage of DEFINE_MACHINE_EXTENDED but still keep
> the boiler plate hidden.

Thanks, I'll go this way, remove unused macros, and keep DEFINE_MACHINE_EXTENDED
and extend both DEFINE_MACHINE_EXTENDED DEFINE_MACHINE supports
"targets" or "arch_mask" parameter.


>
> Regards,
> BALATON Zoltan



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Daniel P. Berrangé]

On Tue, Nov 03, 2026 at 09:48:44PM +0800, Yonggang Luo wrote:
> On Tue, Nov 3, 2026 at 9:23 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >
> > On Tue, 3 Nov 2026, Yonggang Luo wrote:
> > > On Tue, Nov 3, 2026 at 4:16 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > >>
> > >> On Fri, Oct 30, 2026 at 05:51:44PM -0800, Pierrick Bouvier wrote:
> > >>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> > >>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
> > >>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
> > >>>>> type_init
> > >>>>> function that calls type_register_static(). A later change needs to
> > >>>>> pass a
> > >>>>
> > >>>> That's the point of the macro to hide the boiler plate code.
> > >>>>
> > >>>>> target mask into that registration, and the macros have no parameter
> > >>>>> for it.
> > >>>>
> > >>>> Couldn't you just change the macros to take that parameter instead of
> > >>>> expanding it everywhere?
> > >>>>
> > >>>
> > >>> Problem of macros is that they don't have default parameters, so you
> > >>> need variants for everything:
> > >>>
> > >>> DEFINE_MACHINE
> > >>> DEFINE_MACHINE_EXTENDED
> > >>> DEFINE_MACHINE_WITH_INTERFACES
> > >>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> > >>> and now would need a new variant, with variant for other existing ones.
> > >>>
> > >>> In the end, it's just simpler to remove this and add the boilerplate.
> > >>> It's written once and never modified, so using a macro just save typing
> > >>> those lines once.
> > >>
> > >> For each machine, it is only written once, but we add machines
> > >> over time, and every time a new machine is added the code style
> > >> is slightly different. We introduced all the variuos DEFINE_*
> > >> macros for QOM to better ensure consistent style and usage as
> > >> new code is added over time.
> > >
> > > I understand that the DEFINE_* macros are bloating because of this.
> > > Indeed currently the only two macros used are "DEFINE_MACHINE" and
> > > "DEFINE_MACHINE_EXTENDED"
> >
> > There are a few machines using some others but these are the most used.
> > That suggests maybe we should change the convenience wrappers to match
> > what machines need but DEFINE_MACHINE_EXTENDED is meant to be the one that
> > allows all parameters which should be rarely needed.
> >
> > > ; each time people want to add a new attribute, the macros is twiced.
> >
> > Not necessarily. The SECURE parameter did that to preserve previous
> > behaviour but if you add new parameter changing all callers (which is the
> > same as expanding the macro that would also change all callers) then it's
> > just a new parameter added not changing the number of DEFINE_MACHINE*
> > wrappers. Rearranging the wrappers to make DEFINE_MACHINE_EXTENDED used
> > less is an independent change.
> >
> > > And the usage of DEFINE_MACHINE_EXTENDED is rare and can be replaced
> > > with DEFINE_TYPES or TypeInfo
> > > and be more explicit. When we used as macro parameter, we need think
> >
> > But that defies the purpose of hiding the QOM boiler plate as much as
> > possible. New people are confused by QOM and it's easier for them to look
> > up documentation on the DEFINE_MACHINE* macros to see what parameter is
> > what and not care about how it's stored in QOM TypeInfo or what is that
> > at all.
> >
> > > what's that parameter means, and for
> > > TypeInfo, we can directly know what that member is about(because we
> > > are assigned with the member name).
> >
> > The parameter also has a name and documentation so it's not simpler to
> > look up TypeInfo than look at the macro definition or docs. In fact it's
> > harder to guess from TypeInfo as then you also need to get into QOM.
> >
> > > That's why I suggest keeping a single DEFINE_MACHINE, just like
> > > DEFINE_TYPES; as they are the most
> > > used macros(and simple enough), and won't suffer from changes much.
> >
> > That means exposing all the boiler plate for all machines other than the
> > simplest case. I think it would be better to keep DEFINE_MACHINE_EXTENDED
> > but maybe rethink the existing wrappers and drop unused ones and maybe add
> > new ones that reduce the usage of DEFINE_MACHINE_EXTENDED but still keep
> > the boiler plate hidden.
> 
> Thanks, I'll go this way, remove unused macros, and keep DEFINE_MACHINE_EXTENDED
> and extend both DEFINE_MACHINE_EXTENDED DEFINE_MACHINE supports
> "targets" or "arch_mask" parameter.

Given that we don't need to do general per-arch type filtering in
QOM, we could just move 'is_available' out of TypeInfo, and into the
MachineClass, so it is a regular class level property, which can be
set in the class_init methods, and thus avoid any changes to the
DEFINE_MACHINE macros.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

On Tue, Nov 3, 2026 at 9:55 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Tue, Nov 03, 2026 at 09:48:44PM +0800, Yonggang Luo wrote:
> > On Tue, Nov 3, 2026 at 9:23 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> > >
> > > On Tue, 3 Nov 2026, Yonggang Luo wrote:
> > > > On Tue, Nov 3, 2026 at 4:16 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > >>
> > > >> On Fri, Oct 30, 2026 at 05:51:44PM -0800, Pierrick Bouvier wrote:
> > > >>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> > > >>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
> > > >>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
> > > >>>>> type_init
> > > >>>>> function that calls type_register_static(). A later change needs to
> > > >>>>> pass a
> > > >>>>
> > > >>>> That's the point of the macro to hide the boiler plate code.
> > > >>>>
> > > >>>>> target mask into that registration, and the macros have no parameter
> > > >>>>> for it.
> > > >>>>
> > > >>>> Couldn't you just change the macros to take that parameter instead of
> > > >>>> expanding it everywhere?
> > > >>>>
> > > >>>
> > > >>> Problem of macros is that they don't have default parameters, so you
> > > >>> need variants for everything:
> > > >>>
> > > >>> DEFINE_MACHINE
> > > >>> DEFINE_MACHINE_EXTENDED
> > > >>> DEFINE_MACHINE_WITH_INTERFACES
> > > >>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> > > >>> and now would need a new variant, with variant for other existing ones.
> > > >>>
> > > >>> In the end, it's just simpler to remove this and add the boilerplate.
> > > >>> It's written once and never modified, so using a macro just save typing
> > > >>> those lines once.
> > > >>
> > > >> For each machine, it is only written once, but we add machines
> > > >> over time, and every time a new machine is added the code style
> > > >> is slightly different. We introduced all the variuos DEFINE_*
> > > >> macros for QOM to better ensure consistent style and usage as
> > > >> new code is added over time.
> > > >
> > > > I understand that the DEFINE_* macros are bloating because of this.
> > > > Indeed currently the only two macros used are "DEFINE_MACHINE" and
> > > > "DEFINE_MACHINE_EXTENDED"
> > >
> > > There are a few machines using some others but these are the most used.
> > > That suggests maybe we should change the convenience wrappers to match
> > > what machines need but DEFINE_MACHINE_EXTENDED is meant to be the one that
> > > allows all parameters which should be rarely needed.
> > >
> > > > ; each time people want to add a new attribute, the macros is twiced.
> > >
> > > Not necessarily. The SECURE parameter did that to preserve previous
> > > behaviour but if you add new parameter changing all callers (which is the
> > > same as expanding the macro that would also change all callers) then it's
> > > just a new parameter added not changing the number of DEFINE_MACHINE*
> > > wrappers. Rearranging the wrappers to make DEFINE_MACHINE_EXTENDED used
> > > less is an independent change.
> > >
> > > > And the usage of DEFINE_MACHINE_EXTENDED is rare and can be replaced
> > > > with DEFINE_TYPES or TypeInfo
> > > > and be more explicit. When we used as macro parameter, we need think
> > >
> > > But that defies the purpose of hiding the QOM boiler plate as much as
> > > possible. New people are confused by QOM and it's easier for them to look
> > > up documentation on the DEFINE_MACHINE* macros to see what parameter is
> > > what and not care about how it's stored in QOM TypeInfo or what is that
> > > at all.
> > >
> > > > what's that parameter means, and for
> > > > TypeInfo, we can directly know what that member is about(because we
> > > > are assigned with the member name).
> > >
> > > The parameter also has a name and documentation so it's not simpler to
> > > look up TypeInfo than look at the macro definition or docs. In fact it's
> > > harder to guess from TypeInfo as then you also need to get into QOM.
> > >
> > > > That's why I suggest keeping a single DEFINE_MACHINE, just like
> > > > DEFINE_TYPES; as they are the most
> > > > used macros(and simple enough), and won't suffer from changes much.
> > >
> > > That means exposing all the boiler plate for all machines other than the
> > > simplest case. I think it would be better to keep DEFINE_MACHINE_EXTENDED
> > > but maybe rethink the existing wrappers and drop unused ones and maybe add
> > > new ones that reduce the usage of DEFINE_MACHINE_EXTENDED but still keep
> > > the boiler plate hidden.
> >
> > Thanks, I'll go this way, remove unused macros, and keep DEFINE_MACHINE_EXTENDED
> > and extend both DEFINE_MACHINE_EXTENDED DEFINE_MACHINE supports
> > "targets" or "arch_mask" parameter.
>
> Given that we don't need to do general per-arch type filtering in
> QOM, we could just move 'is_available' out of TypeInfo, and into the

We do need general per-arch type filtering, not only the Machine,
Device also suffer from
this. So are the CPU QOM objects. Here the MR needs that
https://lore.kernel.org/qemu-devel/20261031164009.2048-1-luoyonggang@gmail.com/

And the add targets/arch_mask to
DEFINE_MACHINE_EXTENDED/DEFINE_MACHINE is for removing 'is_available'
latter, as is_available has restriction that can not works well for
target_heterogeneous


> MachineClass, so it is a regular class level property, which can be
> set in the class_init methods, and thus avoid any changes to the
> DEFINE_MACHINE macros.
>
> With regards,
> Daniel
> --
> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|
>


-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

Re: [PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo]

On Tue, Nov 3, 2026 at 9:55 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Tue, Nov 03, 2026 at 09:48:44PM +0800, Yonggang Luo wrote:
> > On Tue, Nov 3, 2026 at 9:23 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> > >
> > > On Tue, 3 Nov 2026, Yonggang Luo wrote:
> > > > On Tue, Nov 3, 2026 at 4:16 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > >>
> > > >> On Fri, Oct 30, 2026 at 05:51:44PM -0800, Pierrick Bouvier wrote:
> > > >>> On 10/30/2026 4:09 PM, BALATON Zoltan wrote:
> > > >>>> On Fri, 30 Oct 2026, Yonggang Luo wrote:
> > > >>>>> DEFINE_MACHINE and DEFINE_MACHINE_EXTENDED hide the TypeInfo and the
> > > >>>>> type_init
> > > >>>>> function that calls type_register_static(). A later change needs to
> > > >>>>> pass a
> > > >>>>
> > > >>>> That's the point of the macro to hide the boiler plate code.
> > > >>>>
> > > >>>>> target mask into that registration, and the macros have no parameter
> > > >>>>> for it.
> > > >>>>
> > > >>>> Couldn't you just change the macros to take that parameter instead of
> > > >>>> expanding it everywhere?
> > > >>>>
> > > >>>
> > > >>> Problem of macros is that they don't have default parameters, so you
> > > >>> need variants for everything:
> > > >>>
> > > >>> DEFINE_MACHINE
> > > >>> DEFINE_MACHINE_EXTENDED
> > > >>> DEFINE_MACHINE_WITH_INTERFACES
> > > >>> DEFINE_MACHINE_WITH_INTERFACE_ARRAY
> > > >>> and now would need a new variant, with variant for other existing ones.
> > > >>>
> > > >>> In the end, it's just simpler to remove this and add the boilerplate.
> > > >>> It's written once and never modified, so using a macro just save typing
> > > >>> those lines once.
> > > >>
> > > >> For each machine, it is only written once, but we add machines
> > > >> over time, and every time a new machine is added the code style
> > > >> is slightly different. We introduced all the variuos DEFINE_*
> > > >> macros for QOM to better ensure consistent style and usage as
> > > >> new code is added over time.
> > > >
> > > > I understand that the DEFINE_* macros are bloating because of this.
> > > > Indeed currently the only two macros used are "DEFINE_MACHINE" and
> > > > "DEFINE_MACHINE_EXTENDED"
> > >
> > > There are a few machines using some others but these are the most used.
> > > That suggests maybe we should change the convenience wrappers to match
> > > what machines need but DEFINE_MACHINE_EXTENDED is meant to be the one that
> > > allows all parameters which should be rarely needed.
> > >
> > > > ; each time people want to add a new attribute, the macros is twiced.
> > >
> > > Not necessarily. The SECURE parameter did that to preserve previous
> > > behaviour but if you add new parameter changing all callers (which is the
> > > same as expanding the macro that would also change all callers) then it's
> > > just a new parameter added not changing the number of DEFINE_MACHINE*
> > > wrappers. Rearranging the wrappers to make DEFINE_MACHINE_EXTENDED used
> > > less is an independent change.
> > >
> > > > And the usage of DEFINE_MACHINE_EXTENDED is rare and can be replaced
> > > > with DEFINE_TYPES or TypeInfo
> > > > and be more explicit. When we used as macro parameter, we need think
> > >
> > > But that defies the purpose of hiding the QOM boiler plate as much as
> > > possible. New people are confused by QOM and it's easier for them to look
> > > up documentation on the DEFINE_MACHINE* macros to see what parameter is
> > > what and not care about how it's stored in QOM TypeInfo or what is that
> > > at all.
> > >
> > > > what's that parameter means, and for
> > > > TypeInfo, we can directly know what that member is about(because we
> > > > are assigned with the member name).
> > >
> > > The parameter also has a name and documentation so it's not simpler to
> > > look up TypeInfo than look at the macro definition or docs. In fact it's
> > > harder to guess from TypeInfo as then you also need to get into QOM.
> > >
> > > > That's why I suggest keeping a single DEFINE_MACHINE, just like
> > > > DEFINE_TYPES; as they are the most
> > > > used macros(and simple enough), and won't suffer from changes much.
> > >
> > > That means exposing all the boiler plate for all machines other than the
> > > simplest case. I think it would be better to keep DEFINE_MACHINE_EXTENDED
> > > but maybe rethink the existing wrappers and drop unused ones and maybe add
> > > new ones that reduce the usage of DEFINE_MACHINE_EXTENDED but still keep
> > > the boiler plate hidden.
> >
> > Thanks, I'll go this way, remove unused macros, and keep DEFINE_MACHINE_EXTENDED
> > and extend both DEFINE_MACHINE_EXTENDED DEFINE_MACHINE supports
> > "targets" or "arch_mask" parameter.
>
> Given that we don't need to do general per-arch type filtering in
> QOM, we could just move 'is_available' out of TypeInfo, and into the

Hi Daniel,
The "is_available" is used for dealing with the QOM name conflict,
that is before the calling
to MachineClass call or any other class_init.

> MachineClass, so it is a regular class level property, which can be
> set in the class_init methods, and thus avoid any changes to the
> DEFINE_MACHINE macros.
>
> With regards,
> Daniel
> --
> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|
>


-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo