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
