Re: [PATCH 00/11] hw/arm: Define machines as generic QOM types

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

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