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(-)
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
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
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(-) > >
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(-) >> >>
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 :|
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
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
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
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 :|
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
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
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
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
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
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
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
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
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
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
>
>
>
>
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
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
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
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.