All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harsh Prateek Bora <harshpb@linux.ibm.com>
To: "BALATON Zoltan" <balaton@eik.bme.hu>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>
Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
	Richard Henderson <richard.henderson@linaro.org>,
	Pierrick Bouvier <pierrick.bouvier@linaro.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [PATCH v3 11/13] hw/boards: Extend DEFINE_MACHINE macro to cover more use cases
Date: Tue, 21 Oct 2025 10:17:17 +0530	[thread overview]
Message-ID: <fa5751f3-3e72-40cc-aaa3-2ecb66dbdce3@linux.ibm.com> (raw)
In-Reply-To: <814b7e32-07ae-5872-f94f-cf5b04dac2d7@eik.bme.hu>

+ Eduardo, Marcel (since changes in boards.h)

On 10/20/25 21:05, BALATON Zoltan wrote:
> On Mon, 20 Oct 2025, Philippe Mathieu-Daudé wrote:
>> +Pierrick
>>
>> On 20/10/25 17:05, Philippe Mathieu-Daudé wrote:
>>> On 18/10/25 17:11, BALATON Zoltan wrote:
>>>> Add a more general DEFINE_MACHINE_EXTENDED macro and define simpler
>>>> versions with less parameters based on that. This is inspired by how
>>>> the OBJECT_DEFINE macros do this in a similar way to allow using the
>>>> shortened definition in more complex cases too.
>>>>
>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>>>> ---
>>>>   include/hw/boards.h | 16 ++++++++++++++--
>>>>   1 file changed, 14 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/include/hw/boards.h b/include/hw/boards.h
>>>> index 665b620121..fd3d549ff5 100644
>>>> --- a/include/hw/boards.h
>>>> +++ b/include/hw/boards.h
>>>> @@ -762,7 +762,8 @@ struct MachineState {
>>>>           } \
>>>>       } while (0)
>>>> -#define DEFINE_MACHINE(namestr, machine_initfn) \
>>>> +#define DEFINE_MACHINE_EXTENDED(namestr, PARENT_NAME, InstanceName, \
>>>> +                                machine_initfn, ABSTRACT, ...) \
>>>>       static void machine_initfn##_class_init(ObjectClass *oc, const 
>>>> void *data) \
>>>>       { \
>>>>           MachineClass *mc = MACHINE_CLASS(oc); \
>>>> @@ -770,8 +771,11 @@ struct MachineState {
>>>>       } \
>>>>       static const TypeInfo machine_initfn##_typeinfo = { \
>>>>           .name       = MACHINE_TYPE_NAME(namestr), \
>>>> -        .parent     = TYPE_MACHINE, \
>>>> +        .parent     = TYPE_##PARENT_NAME, \
>>>>           .class_init = machine_initfn##_class_init, \
>>>> +        .instance_size = sizeof(InstanceName), \
>>>> +        .abstract = ABSTRACT, \
>>
>> IIUC we don't want to have abstract type with interfaces, but
>> only QOM leaves. So maybe better always use .abstract = false in
>> DEFINE_MACHINE_EXTENDED()?
> 
> Where did you get that from? What about these then:
> 
> static const TypeInfo pnv_psi_info
> static const TypeInfo spapr_machine_info
> static const TypeInfo e1000_base_info
> static const TypeInfo ivshmem_common_info
> static const TypeInfo macio_type_info
> static const TypeInfo bus_info
> static const TypeInfo device_type_info
> static const TypeInfo hppa_machine_types
> static const TypeInfo qxl_pci_type_info
> static const TypeInfo pic_common_type
> static const TypeInfo xive2_router_info
> static const TypeInfo arm_gic_common_type
> static const TypeInfo arm_gicv3_common_type
> static const TypeInfo ioapic_common_type
> static const TypeInfo loongarch_extioi_common_types
> static const TypeInfo rp_info
> static const TypeInfo virt_machine_info (hw/arm/virt.c)
> static const TypeInfo mps2tz_info
> static const TypeInfo armsse_info
> static const TypeInfo m48txx_isa_type_info
> static const TypeInfo m48txx_sysbus_type_info
> static const TypeInfo pci_ide_type_info
> static const TypeInfo ccw_machine_info
> static const TypeInfo virtio_ccw_md_info
> static const TypeInfo pc_machine_info
> static const TypeInfo x86_machine_info
> static const TypeInfo vfio_pci_device_info
> static const TypeInfo ehci_pci_type_info
> static const TypeInfo xhci_pci_info
> static const TypeInfo uhci_pci_type_info
> static const TypeInfo via_pm_info
> static const TypeInfo via_isa_info
> static const TypeInfo piix_pci_type_info
> static const TypeInfo pcie_slot_type_info
> static const TypeInfo pci_bridge_type_info
> static const TypeInfo intel_hda_info
> static const TypeInfo virtio_md_pci_info
> 
>>>> +        .interfaces = (const InterfaceInfo[]) { __VA_ARGS__ } , \
>>>
>>> IIUC Richard asked for array argument in order to save .rodata?
> 
> Do you have an example for that? I'm not sure what do you mean.
> 
> Regards,
> BALATON Zoltan
> 
>>>>       }; \
>>>>       static void machine_initfn##_register_types(void) \
>>>>       { \
>>>> @@ -779,6 +783,14 @@ struct MachineState {
>>>>       } \
>>>>       type_init(machine_initfn##_register_types)
>>>> +#define DEFINE_MACHINE(namestr, machine_initfn) \
>>>> +    DEFINE_MACHINE_EXTENDED(namestr, MACHINE, MachineState, 
>>>> machine_initfn, \
>>>> +                            false, { })
>>>> +
>>>> +#define DEFINE_MACHINE_WITH_INTERFACES(namestr, machine_initfn, ...) \
>>>> +    DEFINE_MACHINE_EXTENDED(namestr, MACHINE, MachineState, 
>>>> machine_initfn, \
>>>> +                            false, __VA_ARGS__)
>>>> +
>>>>   extern GlobalProperty hw_compat_10_1[];
>>>>   extern const size_t hw_compat_10_1_len;
>>
>>


  reply	other threads:[~2025-10-21  4:48 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-18 15:11 [PATCH v3 00/13] Pegasos2 clean up and pegasos1 emulation BALATON Zoltan
2025-10-18 15:11 ` [PATCH v3 01/13] ppc/vof: Make nextprop behave more like Open Firmware BALATON Zoltan
2025-10-18 15:11 ` [PATCH v3 02/13] hw/ppc/pegasos2: Remove explicit name properties from device tree BALATON Zoltan
2025-10-18 15:11 ` [PATCH v3 03/13] hw/ppc/pegasos2: Change device tree generation BALATON Zoltan
2025-10-20  8:47   ` Philippe Mathieu-Daudé
2025-10-20 13:06     ` BALATON Zoltan
2025-10-20 15:04       ` Philippe Mathieu-Daudé
2025-10-20  8:54   ` Philippe Mathieu-Daudé
2025-10-20 13:02     ` BALATON Zoltan
2025-10-18 15:11 ` [PATCH v3 04/13] hw/ppc/pegasos2: Remove fdt pointer from machine state BALATON Zoltan
2025-10-20  8:48   ` Philippe Mathieu-Daudé
2025-10-18 15:11 ` [PATCH v3 05/13] hw/ppc/pegasos2: Rename mv field in " BALATON Zoltan
2025-10-18 15:11 ` [PATCH v3 06/13] hw/ppc/pegasos2: Add south bridge pointer in the " BALATON Zoltan
2025-10-18 15:11 ` [PATCH v3 07/13] hw/ppc/pegasos2: Move PCI IRQ routing setup to a function BALATON Zoltan
2025-10-18 15:11 ` [PATCH v3 08/13] hw/ppc/pegasos2: Move hardware specific parts out of machine reset BALATON Zoltan
2025-10-18 15:11 ` [PATCH v3 09/13] hw/ppc/pegasos2: Introduce abstract superclass BALATON Zoltan
2025-10-20  8:49   ` Philippe Mathieu-Daudé
2025-10-18 15:11 ` [PATCH v3 10/13] hw/ppc/pegasos2: Add bus frequency to machine state BALATON Zoltan
2025-10-20  8:53   ` Philippe Mathieu-Daudé
2025-10-20 13:26     ` BALATON Zoltan
2025-10-18 15:11 ` [PATCH v3 11/13] hw/boards: Extend DEFINE_MACHINE macro to cover more use cases BALATON Zoltan
2025-10-20 15:05   ` Philippe Mathieu-Daudé
2025-10-20 15:11     ` Philippe Mathieu-Daudé
2025-10-20 15:32       ` Philippe Mathieu-Daudé
2025-10-20 15:40         ` BALATON Zoltan
2025-10-20 15:35       ` BALATON Zoltan
2025-10-21  4:47         ` Harsh Prateek Bora [this message]
2025-10-18 15:11 ` [PATCH v3 12/13] hw/ppc/pegasos2: Add Pegasos I emulation BALATON Zoltan
2025-10-18 15:11 ` [PATCH v3 13/13] hw/ppc/pegasos2: Add VOF support for pegasos1 BALATON Zoltan
2025-10-19  6:56 ` [PATCH v3 00/13] Pegasos2 clean up and pegasos1 emulation Yogesh Vyas
2025-10-19 12:07   ` BALATON Zoltan
2025-10-26  5:49     ` Yogesh Vyas
2025-10-26 11:09       ` BALATON Zoltan
2025-10-26 13:18         ` Yogesh Vyas
2025-10-26 16:44           ` BALATON Zoltan
2025-10-26 16:45           ` BALATON Zoltan
2025-10-27 14:24             ` Yogesh Vyas
2025-10-27 20:18               ` BALATON Zoltan
2025-11-02 16:17                 ` Yogesh Vyas
2025-11-03 20:27                   ` BALATON Zoltan
2025-11-06 22:20                     ` BALATON Zoltan
2025-11-08 19:25                       ` BALATON Zoltan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fa5751f3-3e72-40cc-aaa3-2ecb66dbdce3@linux.ibm.com \
    --to=harshpb@linux.ibm.com \
    --cc=armbru@redhat.com \
    --cc=balaton@eik.bme.hu \
    --cc=eduardo@habkost.net \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=npiggin@gmail.com \
    --cc=philmd@linaro.org \
    --cc=pierrick.bouvier@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.