| Message ID | 20250417235814.98677-1-philmd@linaro.org |
|---|---|
| Headers | show |
| Series | hw/arm: Define machines as generic QOM types | expand |
On 4/17/25 16:58, Philippe Mathieu-Daudé wrote: > While DEFINE_MACHINE() is a succinct macro, it doesn't > allow registering QOM interfaces to the defined machine. > Convert to the generic DEFINE_TYPES() in preparation to > register interfaces. > > Philippe Mathieu-Daudé (11): > hw/core/null-machine: Define machine as generic QOM type > hw/arm/bananapi: Define machine as generic QOM type > hw/arm/cubieboard: Define machine as generic QOM type > hw/arm/digic: Define machine as generic QOM type > hw/arm/imx: Define machines as generic QOM types > hw/arm/integratorcp: Define machine as generic QOM type > hw/arm/kzm: Define machine as generic QOM type > hw/arm/msf2: Define machine as generic QOM type > hw/arm/musicpal: Define machine as generic QOM type > hw/arm/orangepi: Define machine as generic QOM type > hw/arm/stm32: Define machines as generic QOM types > > hw/arm/bananapi_m2u.c | 13 +++++++++++-- > hw/arm/cubieboard.c | 13 +++++++++++-- > hw/arm/digic_boards.c | 14 ++++++++++++-- > hw/arm/imx25_pdk.c | 14 ++++++++++++-- > hw/arm/imx8mp-evk.c | 15 +++++++++++++-- > hw/arm/integratorcp.c | 16 +++++++++++++--- > hw/arm/kzm.c | 14 ++++++++++++-- > hw/arm/mcimx6ul-evk.c | 15 +++++++++++++-- > hw/arm/mcimx7d-sabre.c | 15 +++++++++++++-- > hw/arm/msf2-som.c | 13 +++++++++++-- > hw/arm/musicpal.c | 16 +++++++++++++--- > hw/arm/netduino2.c | 13 +++++++++++-- > hw/arm/netduinoplus2.c | 13 +++++++++++-- > hw/arm/olimex-stm32-h405.c | 13 +++++++++++-- > hw/arm/orangepi.c | 13 +++++++++++-- > hw/arm/sabrelite.c | 14 ++++++++++++-- > hw/arm/stm32vldiscovery.c | 13 +++++++++++-- > hw/core/null-machine.c | 14 ++++++++++++-- > 18 files changed, 213 insertions(+), 38 deletions(-) > Sounds good, for the whole series: Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
On Fri, 18 Apr 2025, Philippe Mathieu-Daudé wrote: > While DEFINE_MACHINE() is a succinct macro, it doesn't > allow registering QOM interfaces to the defined machine. > Convert to the generic DEFINE_TYPES() in preparation to > register interfaces. > > Philippe Mathieu-Daudé (11): > hw/core/null-machine: Define machine as generic QOM type > hw/arm/bananapi: Define machine as generic QOM type > hw/arm/cubieboard: Define machine as generic QOM type > hw/arm/digic: Define machine as generic QOM type > hw/arm/imx: Define machines as generic QOM types > hw/arm/integratorcp: Define machine as generic QOM type > hw/arm/kzm: Define machine as generic QOM type > hw/arm/msf2: Define machine as generic QOM type > hw/arm/musicpal: Define machine as generic QOM type > hw/arm/orangepi: Define machine as generic QOM type > hw/arm/stm32: Define machines as generic QOM types > > hw/arm/bananapi_m2u.c | 13 +++++++++++-- > hw/arm/cubieboard.c | 13 +++++++++++-- > hw/arm/digic_boards.c | 14 ++++++++++++-- > hw/arm/imx25_pdk.c | 14 ++++++++++++-- > hw/arm/imx8mp-evk.c | 15 +++++++++++++-- > hw/arm/integratorcp.c | 16 +++++++++++++--- > hw/arm/kzm.c | 14 ++++++++++++-- > hw/arm/mcimx6ul-evk.c | 15 +++++++++++++-- > hw/arm/mcimx7d-sabre.c | 15 +++++++++++++-- > hw/arm/msf2-som.c | 13 +++++++++++-- > hw/arm/musicpal.c | 16 +++++++++++++--- > hw/arm/netduino2.c | 13 +++++++++++-- > hw/arm/netduinoplus2.c | 13 +++++++++++-- > hw/arm/olimex-stm32-h405.c | 13 +++++++++++-- > hw/arm/orangepi.c | 13 +++++++++++-- > hw/arm/sabrelite.c | 14 ++++++++++++-- > hw/arm/stm32vldiscovery.c | 13 +++++++++++-- > hw/core/null-machine.c | 14 ++++++++++++-- > 18 files changed, 213 insertions(+), 38 deletions(-) This is much longer and exposing boiler plate code. Is it possible instead to change DEFINE_MACHINE or add another similar macro that allows specifying more details such as class state type and interfaces like we already have for OBJECT_DEFINE macros to keep the boiler plate code hidden and not bring it back? Regards, BALATON Zoltan
On 4/18/25 01:53, BALATON Zoltan wrote: > On Fri, 18 Apr 2025, Philippe Mathieu-Daudé wrote: >> While DEFINE_MACHINE() is a succinct macro, it doesn't >> allow registering QOM interfaces to the defined machine. >> Convert to the generic DEFINE_TYPES() in preparation to >> register interfaces. >> >> Philippe Mathieu-Daudé (11): >> hw/core/null-machine: Define machine as generic QOM type >> hw/arm/bananapi: Define machine as generic QOM type >> hw/arm/cubieboard: Define machine as generic QOM type >> hw/arm/digic: Define machine as generic QOM type >> hw/arm/imx: Define machines as generic QOM types >> hw/arm/integratorcp: Define machine as generic QOM type >> hw/arm/kzm: Define machine as generic QOM type >> hw/arm/msf2: Define machine as generic QOM type >> hw/arm/musicpal: Define machine as generic QOM type >> hw/arm/orangepi: Define machine as generic QOM type >> hw/arm/stm32: Define machines as generic QOM types >> >> hw/arm/bananapi_m2u.c | 13 +++++++++++-- >> hw/arm/cubieboard.c | 13 +++++++++++-- >> hw/arm/digic_boards.c | 14 ++++++++++++-- >> hw/arm/imx25_pdk.c | 14 ++++++++++++-- >> hw/arm/imx8mp-evk.c | 15 +++++++++++++-- >> hw/arm/integratorcp.c | 16 +++++++++++++--- >> hw/arm/kzm.c | 14 ++++++++++++-- >> hw/arm/mcimx6ul-evk.c | 15 +++++++++++++-- >> hw/arm/mcimx7d-sabre.c | 15 +++++++++++++-- >> hw/arm/msf2-som.c | 13 +++++++++++-- >> hw/arm/musicpal.c | 16 +++++++++++++--- >> hw/arm/netduino2.c | 13 +++++++++++-- >> hw/arm/netduinoplus2.c | 13 +++++++++++-- >> hw/arm/olimex-stm32-h405.c | 13 +++++++++++-- >> hw/arm/orangepi.c | 13 +++++++++++-- >> hw/arm/sabrelite.c | 14 ++++++++++++-- >> hw/arm/stm32vldiscovery.c | 13 +++++++++++-- >> hw/core/null-machine.c | 14 ++++++++++++-- >> 18 files changed, 213 insertions(+), 38 deletions(-) > > This is much longer and exposing boiler plate code. Is it possible instead > to change DEFINE_MACHINE or add another similar macro that allows > specifying more details such as class state type and interfaces like we > already have for OBJECT_DEFINE macros to keep the boiler plate code hidden > and not bring it back? > We can eventually modify DEFINE_MACHINES, to take an additional interfaces parameter, and replace all call sites, with an empty list for all boards out of hw/arm. As long as we avoid something like: DEFINE_MACHINES_WITH_INTERFACE_1(...) DEFINE_MACHINES_WITH_INTERFACE_2(...) DEFINE_MACHINES_WITH_INTERFACE_3(...) I'm ok with keeping the macro. Would that work for you folks? > Regards, > BALATON Zoltan
On 18/4/25 18:33, Pierrick Bouvier wrote: > On 4/18/25 01:53, BALATON Zoltan wrote: >> On Fri, 18 Apr 2025, Philippe Mathieu-Daudé wrote: >>> While DEFINE_MACHINE() is a succinct macro, it doesn't >>> allow registering QOM interfaces to the defined machine. >>> Convert to the generic DEFINE_TYPES() in preparation to >>> register interfaces. >>> >>> Philippe Mathieu-Daudé (11): >>> hw/core/null-machine: Define machine as generic QOM type >>> hw/arm/bananapi: Define machine as generic QOM type >>> hw/arm/cubieboard: Define machine as generic QOM type >>> hw/arm/digic: Define machine as generic QOM type >>> hw/arm/imx: Define machines as generic QOM types >>> hw/arm/integratorcp: Define machine as generic QOM type >>> hw/arm/kzm: Define machine as generic QOM type >>> hw/arm/msf2: Define machine as generic QOM type >>> hw/arm/musicpal: Define machine as generic QOM type >>> hw/arm/orangepi: Define machine as generic QOM type >>> hw/arm/stm32: Define machines as generic QOM types >>> >>> hw/arm/bananapi_m2u.c | 13 +++++++++++-- >>> hw/arm/cubieboard.c | 13 +++++++++++-- >>> hw/arm/digic_boards.c | 14 ++++++++++++-- >>> hw/arm/imx25_pdk.c | 14 ++++++++++++-- >>> hw/arm/imx8mp-evk.c | 15 +++++++++++++-- >>> hw/arm/integratorcp.c | 16 +++++++++++++--- >>> hw/arm/kzm.c | 14 ++++++++++++-- >>> hw/arm/mcimx6ul-evk.c | 15 +++++++++++++-- >>> hw/arm/mcimx7d-sabre.c | 15 +++++++++++++-- >>> hw/arm/msf2-som.c | 13 +++++++++++-- >>> hw/arm/musicpal.c | 16 +++++++++++++--- >>> hw/arm/netduino2.c | 13 +++++++++++-- >>> hw/arm/netduinoplus2.c | 13 +++++++++++-- >>> hw/arm/olimex-stm32-h405.c | 13 +++++++++++-- >>> hw/arm/orangepi.c | 13 +++++++++++-- >>> hw/arm/sabrelite.c | 14 ++++++++++++-- >>> hw/arm/stm32vldiscovery.c | 13 +++++++++++-- >>> hw/core/null-machine.c | 14 ++++++++++++-- >>> 18 files changed, 213 insertions(+), 38 deletions(-) >> >> This is much longer and exposing boiler plate code. Is it possible >> instead >> to change DEFINE_MACHINE or add another similar macro that allows >> specifying more details such as class state type and interfaces like we >> already have for OBJECT_DEFINE macros to keep the boiler plate code >> hidden >> and not bring it back? >> > > We can eventually modify DEFINE_MACHINES, to take an additional > interfaces parameter, and replace all call sites, with an empty list for > all boards out of hw/arm. > > As long as we avoid something like: > DEFINE_MACHINES_WITH_INTERFACE_1(...) > DEFINE_MACHINES_WITH_INTERFACE_2(...) > DEFINE_MACHINES_WITH_INTERFACE_3(...) > I'm ok with keeping the macro. > > Would that work for you folks? But then we'll want DEFINE_PPC32_MACHINE() -> DEFINE_MACHINES_WITH_INTERFACE_1() etc... We want to eventually use declarative file to structure most of the machine boiler plate code. Maybe being momentarily verbose is acceptable...
On 4/18/25 09:59, Philippe Mathieu-Daudé wrote: > On 18/4/25 18:33, Pierrick Bouvier wrote: >> On 4/18/25 01:53, BALATON Zoltan wrote: >>> On Fri, 18 Apr 2025, Philippe Mathieu-Daudé wrote: >>>> While DEFINE_MACHINE() is a succinct macro, it doesn't >>>> allow registering QOM interfaces to the defined machine. >>>> Convert to the generic DEFINE_TYPES() in preparation to >>>> register interfaces. >>>> >>>> Philippe Mathieu-Daudé (11): >>>> hw/core/null-machine: Define machine as generic QOM type >>>> hw/arm/bananapi: Define machine as generic QOM type >>>> hw/arm/cubieboard: Define machine as generic QOM type >>>> hw/arm/digic: Define machine as generic QOM type >>>> hw/arm/imx: Define machines as generic QOM types >>>> hw/arm/integratorcp: Define machine as generic QOM type >>>> hw/arm/kzm: Define machine as generic QOM type >>>> hw/arm/msf2: Define machine as generic QOM type >>>> hw/arm/musicpal: Define machine as generic QOM type >>>> hw/arm/orangepi: Define machine as generic QOM type >>>> hw/arm/stm32: Define machines as generic QOM types >>>> >>>> hw/arm/bananapi_m2u.c | 13 +++++++++++-- >>>> hw/arm/cubieboard.c | 13 +++++++++++-- >>>> hw/arm/digic_boards.c | 14 ++++++++++++-- >>>> hw/arm/imx25_pdk.c | 14 ++++++++++++-- >>>> hw/arm/imx8mp-evk.c | 15 +++++++++++++-- >>>> hw/arm/integratorcp.c | 16 +++++++++++++--- >>>> hw/arm/kzm.c | 14 ++++++++++++-- >>>> hw/arm/mcimx6ul-evk.c | 15 +++++++++++++-- >>>> hw/arm/mcimx7d-sabre.c | 15 +++++++++++++-- >>>> hw/arm/msf2-som.c | 13 +++++++++++-- >>>> hw/arm/musicpal.c | 16 +++++++++++++--- >>>> hw/arm/netduino2.c | 13 +++++++++++-- >>>> hw/arm/netduinoplus2.c | 13 +++++++++++-- >>>> hw/arm/olimex-stm32-h405.c | 13 +++++++++++-- >>>> hw/arm/orangepi.c | 13 +++++++++++-- >>>> hw/arm/sabrelite.c | 14 ++++++++++++-- >>>> hw/arm/stm32vldiscovery.c | 13 +++++++++++-- >>>> hw/core/null-machine.c | 14 ++++++++++++-- >>>> 18 files changed, 213 insertions(+), 38 deletions(-) >>> >>> This is much longer and exposing boiler plate code. Is it possible >>> instead >>> to change DEFINE_MACHINE or add another similar macro that allows >>> specifying more details such as class state type and interfaces like we >>> already have for OBJECT_DEFINE macros to keep the boiler plate code >>> hidden >>> and not bring it back? >>> >> >> We can eventually modify DEFINE_MACHINES, to take an additional >> interfaces parameter, and replace all call sites, with an empty list for >> all boards out of hw/arm. >> >> As long as we avoid something like: >> DEFINE_MACHINES_WITH_INTERFACE_1(...) >> DEFINE_MACHINES_WITH_INTERFACE_2(...) >> DEFINE_MACHINES_WITH_INTERFACE_3(...) >> I'm ok with keeping the macro. >> >> Would that work for you folks? > > But then we'll want DEFINE_PPC32_MACHINE() -> > DEFINE_MACHINES_WITH_INTERFACE_1() etc... > We can see that later when touching other targets. For now, DEFINE_MACHINE is not used in a lot of places, so replacing call sites should be easy, and it will cover hw/arm, which is our point of interest now. > We want to eventually use declarative file to structure most of the > machine boiler plate code. Maybe being momentarily verbose is > acceptable...
On 18/4/25 19:03, Pierrick Bouvier wrote: > On 4/18/25 09:59, Philippe Mathieu-Daudé wrote: >> On 18/4/25 18:33, Pierrick Bouvier wrote: >>> On 4/18/25 01:53, BALATON Zoltan wrote: >>>> On Fri, 18 Apr 2025, Philippe Mathieu-Daudé wrote: >>>>> While DEFINE_MACHINE() is a succinct macro, it doesn't >>>>> allow registering QOM interfaces to the defined machine. >>>>> Convert to the generic DEFINE_TYPES() in preparation to >>>>> register interfaces. >>>>> >>>>> Philippe Mathieu-Daudé (11): >>>>> hw/core/null-machine: Define machine as generic QOM type >>>>> hw/arm/bananapi: Define machine as generic QOM type >>>>> hw/arm/cubieboard: Define machine as generic QOM type >>>>> hw/arm/digic: Define machine as generic QOM type >>>>> hw/arm/imx: Define machines as generic QOM types >>>>> hw/arm/integratorcp: Define machine as generic QOM type >>>>> hw/arm/kzm: Define machine as generic QOM type >>>>> hw/arm/msf2: Define machine as generic QOM type >>>>> hw/arm/musicpal: Define machine as generic QOM type >>>>> hw/arm/orangepi: Define machine as generic QOM type >>>>> hw/arm/stm32: Define machines as generic QOM types >>>>> >>>>> hw/arm/bananapi_m2u.c | 13 +++++++++++-- >>>>> hw/arm/cubieboard.c | 13 +++++++++++-- >>>>> hw/arm/digic_boards.c | 14 ++++++++++++-- >>>>> hw/arm/imx25_pdk.c | 14 ++++++++++++-- >>>>> hw/arm/imx8mp-evk.c | 15 +++++++++++++-- >>>>> hw/arm/integratorcp.c | 16 +++++++++++++--- >>>>> hw/arm/kzm.c | 14 ++++++++++++-- >>>>> hw/arm/mcimx6ul-evk.c | 15 +++++++++++++-- >>>>> hw/arm/mcimx7d-sabre.c | 15 +++++++++++++-- >>>>> hw/arm/msf2-som.c | 13 +++++++++++-- >>>>> hw/arm/musicpal.c | 16 +++++++++++++--- >>>>> hw/arm/netduino2.c | 13 +++++++++++-- >>>>> hw/arm/netduinoplus2.c | 13 +++++++++++-- >>>>> hw/arm/olimex-stm32-h405.c | 13 +++++++++++-- >>>>> hw/arm/orangepi.c | 13 +++++++++++-- >>>>> hw/arm/sabrelite.c | 14 ++++++++++++-- >>>>> hw/arm/stm32vldiscovery.c | 13 +++++++++++-- >>>>> hw/core/null-machine.c | 14 ++++++++++++-- >>>>> 18 files changed, 213 insertions(+), 38 deletions(-) >>>> >>>> This is much longer and exposing boiler plate code. Is it possible >>>> instead >>>> to change DEFINE_MACHINE or add another similar macro that allows >>>> specifying more details such as class state type and interfaces like we >>>> already have for OBJECT_DEFINE macros to keep the boiler plate code >>>> hidden >>>> and not bring it back? >>>> >>> >>> We can eventually modify DEFINE_MACHINES, to take an additional >>> interfaces parameter, and replace all call sites, with an empty list for >>> all boards out of hw/arm. >>> >>> As long as we avoid something like: >>> DEFINE_MACHINES_WITH_INTERFACE_1(...) >>> DEFINE_MACHINES_WITH_INTERFACE_2(...) >>> DEFINE_MACHINES_WITH_INTERFACE_3(...) >>> I'm ok with keeping the macro. >>> >>> Would that work for you folks? >> >> But then we'll want DEFINE_PPC32_MACHINE() -> >> DEFINE_MACHINES_WITH_INTERFACE_1() etc... >> > > We can see that later when touching other targets. For now, > DEFINE_MACHINE is not used in a lot of places, so replacing call sites > should be easy, and it will cover hw/arm, which is our point of interest > now. I concur and share the same goal, but here Zoltan is concerned about converting DEFINE_MACHINE to DEFINE_TYPES adds 12 lines of boilerplate code.
On 4/18/25 10:07, Philippe Mathieu-Daudé wrote: > On 18/4/25 19:03, Pierrick Bouvier wrote: >> On 4/18/25 09:59, Philippe Mathieu-Daudé wrote: >>> On 18/4/25 18:33, Pierrick Bouvier wrote: >>>> On 4/18/25 01:53, BALATON Zoltan wrote: >>>>> On Fri, 18 Apr 2025, Philippe Mathieu-Daudé wrote: >>>>>> While DEFINE_MACHINE() is a succinct macro, it doesn't >>>>>> allow registering QOM interfaces to the defined machine. >>>>>> Convert to the generic DEFINE_TYPES() in preparation to >>>>>> register interfaces. >>>>>> >>>>>> Philippe Mathieu-Daudé (11): >>>>>> hw/core/null-machine: Define machine as generic QOM type >>>>>> hw/arm/bananapi: Define machine as generic QOM type >>>>>> hw/arm/cubieboard: Define machine as generic QOM type >>>>>> hw/arm/digic: Define machine as generic QOM type >>>>>> hw/arm/imx: Define machines as generic QOM types >>>>>> hw/arm/integratorcp: Define machine as generic QOM type >>>>>> hw/arm/kzm: Define machine as generic QOM type >>>>>> hw/arm/msf2: Define machine as generic QOM type >>>>>> hw/arm/musicpal: Define machine as generic QOM type >>>>>> hw/arm/orangepi: Define machine as generic QOM type >>>>>> hw/arm/stm32: Define machines as generic QOM types >>>>>> >>>>>> hw/arm/bananapi_m2u.c | 13 +++++++++++-- >>>>>> hw/arm/cubieboard.c | 13 +++++++++++-- >>>>>> hw/arm/digic_boards.c | 14 ++++++++++++-- >>>>>> hw/arm/imx25_pdk.c | 14 ++++++++++++-- >>>>>> hw/arm/imx8mp-evk.c | 15 +++++++++++++-- >>>>>> hw/arm/integratorcp.c | 16 +++++++++++++--- >>>>>> hw/arm/kzm.c | 14 ++++++++++++-- >>>>>> hw/arm/mcimx6ul-evk.c | 15 +++++++++++++-- >>>>>> hw/arm/mcimx7d-sabre.c | 15 +++++++++++++-- >>>>>> hw/arm/msf2-som.c | 13 +++++++++++-- >>>>>> hw/arm/musicpal.c | 16 +++++++++++++--- >>>>>> hw/arm/netduino2.c | 13 +++++++++++-- >>>>>> hw/arm/netduinoplus2.c | 13 +++++++++++-- >>>>>> hw/arm/olimex-stm32-h405.c | 13 +++++++++++-- >>>>>> hw/arm/orangepi.c | 13 +++++++++++-- >>>>>> hw/arm/sabrelite.c | 14 ++++++++++++-- >>>>>> hw/arm/stm32vldiscovery.c | 13 +++++++++++-- >>>>>> hw/core/null-machine.c | 14 ++++++++++++-- >>>>>> 18 files changed, 213 insertions(+), 38 deletions(-) >>>>> >>>>> This is much longer and exposing boiler plate code. Is it possible >>>>> instead >>>>> to change DEFINE_MACHINE or add another similar macro that allows >>>>> specifying more details such as class state type and interfaces like we >>>>> already have for OBJECT_DEFINE macros to keep the boiler plate code >>>>> hidden >>>>> and not bring it back? >>>>> >>>> >>>> We can eventually modify DEFINE_MACHINES, to take an additional >>>> interfaces parameter, and replace all call sites, with an empty list for >>>> all boards out of hw/arm. >>>> >>>> As long as we avoid something like: >>>> DEFINE_MACHINES_WITH_INTERFACE_1(...) >>>> DEFINE_MACHINES_WITH_INTERFACE_2(...) >>>> DEFINE_MACHINES_WITH_INTERFACE_3(...) >>>> I'm ok with keeping the macro. >>>> >>>> Would that work for you folks? >>> >>> But then we'll want DEFINE_PPC32_MACHINE() -> >>> DEFINE_MACHINES_WITH_INTERFACE_1() etc... >>> >> >> We can see that later when touching other targets. For now, >> DEFINE_MACHINE is not used in a lot of places, so replacing call sites >> should be easy, and it will cover hw/arm, which is our point of interest >> now. > > I concur and share the same goal, but here Zoltan is concerned about > converting DEFINE_MACHINE to DEFINE_TYPES adds 12 lines of boilerplate > code. If I understand correctly, Zoltan issue is that we remove usage of DEFINE_MACHINE, and put boilerplate for type definition instead. So hiding boilerplate behind the macro would be ok, thus my proposal. Zoltan, could you please confirm in which way you were qualifying this as boilerplate? Thanks, Pierrick
On Fri, 18 Apr 2025, Philippe Mathieu-Daudé wrote: > On 18/4/25 18:33, Pierrick Bouvier wrote: >> On 4/18/25 01:53, BALATON Zoltan wrote: >>> On Fri, 18 Apr 2025, Philippe Mathieu-Daudé wrote: >>>> While DEFINE_MACHINE() is a succinct macro, it doesn't >>>> allow registering QOM interfaces to the defined machine. >>>> Convert to the generic DEFINE_TYPES() in preparation to >>>> register interfaces. >>>> >>>> Philippe Mathieu-Daudé (11): >>>> hw/core/null-machine: Define machine as generic QOM type >>>> hw/arm/bananapi: Define machine as generic QOM type >>>> hw/arm/cubieboard: Define machine as generic QOM type >>>> hw/arm/digic: Define machine as generic QOM type >>>> hw/arm/imx: Define machines as generic QOM types >>>> hw/arm/integratorcp: Define machine as generic QOM type >>>> hw/arm/kzm: Define machine as generic QOM type >>>> hw/arm/msf2: Define machine as generic QOM type >>>> hw/arm/musicpal: Define machine as generic QOM type >>>> hw/arm/orangepi: Define machine as generic QOM type >>>> hw/arm/stm32: Define machines as generic QOM types >>>> >>>> hw/arm/bananapi_m2u.c | 13 +++++++++++-- >>>> hw/arm/cubieboard.c | 13 +++++++++++-- >>>> hw/arm/digic_boards.c | 14 ++++++++++++-- >>>> hw/arm/imx25_pdk.c | 14 ++++++++++++-- >>>> hw/arm/imx8mp-evk.c | 15 +++++++++++++-- >>>> hw/arm/integratorcp.c | 16 +++++++++++++--- >>>> hw/arm/kzm.c | 14 ++++++++++++-- >>>> hw/arm/mcimx6ul-evk.c | 15 +++++++++++++-- >>>> hw/arm/mcimx7d-sabre.c | 15 +++++++++++++-- >>>> hw/arm/msf2-som.c | 13 +++++++++++-- >>>> hw/arm/musicpal.c | 16 +++++++++++++--- >>>> hw/arm/netduino2.c | 13 +++++++++++-- >>>> hw/arm/netduinoplus2.c | 13 +++++++++++-- >>>> hw/arm/olimex-stm32-h405.c | 13 +++++++++++-- >>>> hw/arm/orangepi.c | 13 +++++++++++-- >>>> hw/arm/sabrelite.c | 14 ++++++++++++-- >>>> hw/arm/stm32vldiscovery.c | 13 +++++++++++-- >>>> hw/core/null-machine.c | 14 ++++++++++++-- >>>> 18 files changed, 213 insertions(+), 38 deletions(-) >>> >>> This is much longer and exposing boiler plate code. Is it possible instead >>> to change DEFINE_MACHINE or add another similar macro that allows >>> specifying more details such as class state type and interfaces like we >>> already have for OBJECT_DEFINE macros to keep the boiler plate code hidden >>> and not bring it back? >>> >> >> We can eventually modify DEFINE_MACHINES, to take an additional interfaces >> parameter, and replace all call sites, with an empty list for all boards >> out of hw/arm. >> >> As long as we avoid something like: >> DEFINE_MACHINES_WITH_INTERFACE_1(...) >> DEFINE_MACHINES_WITH_INTERFACE_2(...) >> DEFINE_MACHINES_WITH_INTERFACE_3(...) >> I'm ok with keeping the macro. >> >> Would that work for you folks? > > But then we'll want DEFINE_PPC32_MACHINE() -> > DEFINE_MACHINES_WITH_INTERFACE_1() etc... > > We want to eventually use declarative file to structure most of the > machine boiler plate code. Maybe being momentarily verbose is > acceptable... Moments in QEMU can last years... I was thinking about similar to OBJECT_DEFINE_SIMPLE_TYPE_WITH_INTERFACES. Would something like that be possible for DEFINE_MACHINE too? Regards, BALATON Zoltan
On Fri, 18 Apr 2025, Pierrick Bouvier wrote: > On 4/18/25 10:07, Philippe Mathieu-Daudé wrote: >> On 18/4/25 19:03, Pierrick Bouvier wrote: >>> On 4/18/25 09:59, Philippe Mathieu-Daudé wrote: >>>> On 18/4/25 18:33, Pierrick Bouvier wrote: >>>>> On 4/18/25 01:53, BALATON Zoltan wrote: >>>>>> On Fri, 18 Apr 2025, Philippe Mathieu-Daudé wrote: >>>>>>> While DEFINE_MACHINE() is a succinct macro, it doesn't >>>>>>> allow registering QOM interfaces to the defined machine. >>>>>>> Convert to the generic DEFINE_TYPES() in preparation to >>>>>>> register interfaces. >>>>>>> >>>>>>> Philippe Mathieu-Daudé (11): >>>>>>> hw/core/null-machine: Define machine as generic QOM type >>>>>>> hw/arm/bananapi: Define machine as generic QOM type >>>>>>> hw/arm/cubieboard: Define machine as generic QOM type >>>>>>> hw/arm/digic: Define machine as generic QOM type >>>>>>> hw/arm/imx: Define machines as generic QOM types >>>>>>> hw/arm/integratorcp: Define machine as generic QOM type >>>>>>> hw/arm/kzm: Define machine as generic QOM type >>>>>>> hw/arm/msf2: Define machine as generic QOM type >>>>>>> hw/arm/musicpal: Define machine as generic QOM type >>>>>>> hw/arm/orangepi: Define machine as generic QOM type >>>>>>> hw/arm/stm32: Define machines as generic QOM types >>>>>>> >>>>>>> hw/arm/bananapi_m2u.c | 13 +++++++++++-- >>>>>>> hw/arm/cubieboard.c | 13 +++++++++++-- >>>>>>> hw/arm/digic_boards.c | 14 ++++++++++++-- >>>>>>> hw/arm/imx25_pdk.c | 14 ++++++++++++-- >>>>>>> hw/arm/imx8mp-evk.c | 15 +++++++++++++-- >>>>>>> hw/arm/integratorcp.c | 16 +++++++++++++--- >>>>>>> hw/arm/kzm.c | 14 ++++++++++++-- >>>>>>> hw/arm/mcimx6ul-evk.c | 15 +++++++++++++-- >>>>>>> hw/arm/mcimx7d-sabre.c | 15 +++++++++++++-- >>>>>>> hw/arm/msf2-som.c | 13 +++++++++++-- >>>>>>> hw/arm/musicpal.c | 16 +++++++++++++--- >>>>>>> hw/arm/netduino2.c | 13 +++++++++++-- >>>>>>> hw/arm/netduinoplus2.c | 13 +++++++++++-- >>>>>>> hw/arm/olimex-stm32-h405.c | 13 +++++++++++-- >>>>>>> hw/arm/orangepi.c | 13 +++++++++++-- >>>>>>> hw/arm/sabrelite.c | 14 ++++++++++++-- >>>>>>> hw/arm/stm32vldiscovery.c | 13 +++++++++++-- >>>>>>> hw/core/null-machine.c | 14 ++++++++++++-- >>>>>>> 18 files changed, 213 insertions(+), 38 deletions(-) >>>>>> >>>>>> This is much longer and exposing boiler plate code. Is it possible >>>>>> instead >>>>>> to change DEFINE_MACHINE or add another similar macro that allows >>>>>> specifying more details such as class state type and interfaces like we >>>>>> already have for OBJECT_DEFINE macros to keep the boiler plate code >>>>>> hidden >>>>>> and not bring it back? >>>>>> >>>>> >>>>> We can eventually modify DEFINE_MACHINES, to take an additional >>>>> interfaces parameter, and replace all call sites, with an empty list for >>>>> all boards out of hw/arm. >>>>> >>>>> As long as we avoid something like: >>>>> DEFINE_MACHINES_WITH_INTERFACE_1(...) >>>>> DEFINE_MACHINES_WITH_INTERFACE_2(...) >>>>> DEFINE_MACHINES_WITH_INTERFACE_3(...) >>>>> I'm ok with keeping the macro. >>>>> >>>>> Would that work for you folks? >>>> >>>> But then we'll want DEFINE_PPC32_MACHINE() -> >>>> DEFINE_MACHINES_WITH_INTERFACE_1() etc... >>>> >>> >>> We can see that later when touching other targets. For now, >>> DEFINE_MACHINE is not used in a lot of places, so replacing call sites >>> should be easy, and it will cover hw/arm, which is our point of interest >>> now. >> >> I concur and share the same goal, but here Zoltan is concerned about >> converting DEFINE_MACHINE to DEFINE_TYPES adds 12 lines of boilerplate >> code. > > If I understand correctly, Zoltan issue is that we remove usage of > DEFINE_MACHINE, and put boilerplate for type definition instead. > So hiding boilerplate behind the macro would be ok, thus my proposal. > > Zoltan, could you please confirm in which way you were qualifying this as > boilerplate? See commit f84203a8c22 and if I remember correctly there was some discussion around that on the list where this came from which was partly started by me being annoyed to have half of a device model consiting of just boiler plate. I would not like that to come back if can be avoided as having these macros make the models much more comprehensive for new people not having to go through all the QOM boiler plate to see the actual functionality. Regards, BALATON Zoltan
On 4/18/25 11:48, BALATON Zoltan wrote: > On Fri, 18 Apr 2025, Philippe Mathieu-Daudé wrote: >> On 18/4/25 18:33, Pierrick Bouvier wrote: >>> On 4/18/25 01:53, BALATON Zoltan wrote: >>>> On Fri, 18 Apr 2025, Philippe Mathieu-Daudé wrote: >>>>> While DEFINE_MACHINE() is a succinct macro, it doesn't >>>>> allow registering QOM interfaces to the defined machine. >>>>> Convert to the generic DEFINE_TYPES() in preparation to >>>>> register interfaces. >>>>> >>>>> Philippe Mathieu-Daudé (11): >>>>> hw/core/null-machine: Define machine as generic QOM type >>>>> hw/arm/bananapi: Define machine as generic QOM type >>>>> hw/arm/cubieboard: Define machine as generic QOM type >>>>> hw/arm/digic: Define machine as generic QOM type >>>>> hw/arm/imx: Define machines as generic QOM types >>>>> hw/arm/integratorcp: Define machine as generic QOM type >>>>> hw/arm/kzm: Define machine as generic QOM type >>>>> hw/arm/msf2: Define machine as generic QOM type >>>>> hw/arm/musicpal: Define machine as generic QOM type >>>>> hw/arm/orangepi: Define machine as generic QOM type >>>>> hw/arm/stm32: Define machines as generic QOM types >>>>> >>>>> hw/arm/bananapi_m2u.c | 13 +++++++++++-- >>>>> hw/arm/cubieboard.c | 13 +++++++++++-- >>>>> hw/arm/digic_boards.c | 14 ++++++++++++-- >>>>> hw/arm/imx25_pdk.c | 14 ++++++++++++-- >>>>> hw/arm/imx8mp-evk.c | 15 +++++++++++++-- >>>>> hw/arm/integratorcp.c | 16 +++++++++++++--- >>>>> hw/arm/kzm.c | 14 ++++++++++++-- >>>>> hw/arm/mcimx6ul-evk.c | 15 +++++++++++++-- >>>>> hw/arm/mcimx7d-sabre.c | 15 +++++++++++++-- >>>>> hw/arm/msf2-som.c | 13 +++++++++++-- >>>>> hw/arm/musicpal.c | 16 +++++++++++++--- >>>>> hw/arm/netduino2.c | 13 +++++++++++-- >>>>> hw/arm/netduinoplus2.c | 13 +++++++++++-- >>>>> hw/arm/olimex-stm32-h405.c | 13 +++++++++++-- >>>>> hw/arm/orangepi.c | 13 +++++++++++-- >>>>> hw/arm/sabrelite.c | 14 ++++++++++++-- >>>>> hw/arm/stm32vldiscovery.c | 13 +++++++++++-- >>>>> hw/core/null-machine.c | 14 ++++++++++++-- >>>>> 18 files changed, 213 insertions(+), 38 deletions(-) >>>> >>>> This is much longer and exposing boiler plate code. Is it possible instead >>>> to change DEFINE_MACHINE or add another similar macro that allows >>>> specifying more details such as class state type and interfaces like we >>>> already have for OBJECT_DEFINE macros to keep the boiler plate code hidden >>>> and not bring it back? >>>> >>> >>> We can eventually modify DEFINE_MACHINES, to take an additional interfaces >>> parameter, and replace all call sites, with an empty list for all boards >>> out of hw/arm. >>> >>> As long as we avoid something like: >>> DEFINE_MACHINES_WITH_INTERFACE_1(...) >>> DEFINE_MACHINES_WITH_INTERFACE_2(...) >>> DEFINE_MACHINES_WITH_INTERFACE_3(...) >>> I'm ok with keeping the macro. >>> >>> Would that work for you folks? >> >> But then we'll want DEFINE_PPC32_MACHINE() -> >> DEFINE_MACHINES_WITH_INTERFACE_1() etc... >> >> We want to eventually use declarative file to structure most of the >> machine boiler plate code. Maybe being momentarily verbose is >> acceptable... > > Moments in QEMU can last years... I was thinking about similar to > OBJECT_DEFINE_SIMPLE_TYPE_WITH_INTERFACES. Would something like that be > possible for DEFINE_MACHINE too? > We can just add the list of interfaces the machine is implementing as an additional parameter to DEFINE_MACHINE, and this solves the problem without adding any boilerplate. Ultimately, we'll need to tag all machines to mention targets supported, so this information has to be written somewhere. > Regards, > BALATON Zoltan