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
