Re: Realize methods realizing "sideways" in the composition tree

[Markus Armbruster]

Peter Maydell  writes:

> On Fri, 15 Jan 2021 at 15:45, Markus Armbruster  wrote:
>>
>> The .realize() method realizes the child at (1).  It should use
>> qdev_realize() like we do everywhere else, since commit ce189ab230
>> "qdev: Convert bus-less devices to qdev_realize() with Coccinelle".
>>
>> It sets a link property from the child back to the parent at (2).  Why
>> do we need a link?  Each QOM Object contains a pointer to its parent,
>> doesn't it?
>
> It does, but what should parent object pointers be used for?
> My assumption is that you'd only use those where you really
> wanted to traverse the QOM tree. Generally I would use a link
> property when I wanted one object to have a pointer to the
> other regardless of what the QOM-tree relationship happens to
> be. Today all the users of XHCIState happen to create it in a
> way that means they're parents of it, but that doesn't seem
> like it should be an inherent requirement that we bake into
> its API.

Makes sense.

I'll post a patch to use qdev_realize().

Thanks!

Re: Realize methods realizing "sideways" in the composition tree

[Peter Maydell]

On Fri, 15 Jan 2021 at 15:45, Markus Armbruster  wrote:
>
> The .realize() method realizes the child at (1).  It should use
> qdev_realize() like we do everywhere else, since commit ce189ab230
> "qdev: Convert bus-less devices to qdev_realize() with Coccinelle".
>
> It sets a link property from the child back to the parent at (2).  Why
> do we need a link?  Each QOM Object contains a pointer to its parent,
> doesn't it?

It does, but what should parent object pointers be used for?
My assumption is that you'd only use those where you really
wanted to traverse the QOM tree. Generally I would use a link
property when I wanted one object to have a pointer to the
other regardless of what the QOM-tree relationship happens to
be. Today all the users of XHCIState happen to create it in a
way that means they're parents of it, but that doesn't seem
like it should be an inherent requirement that we bake into
its API.

thanks
-- PMM

Realize methods realizing "sideways" in the composition tree

[Markus Armbruster]

Perhaps I'm slow on the uptake today...

We have

typedef struct XHCIPciState {
/*< private >*/
PCIDevice parent_obj;
/*< public >*/
(1) XHCIState xhci;
OnOffAuto msi;
OnOffAuto msix;
} XHCIPciState;

This is a PCI device that contains a (bus-less) TYPE_XHCI device, at
(1).

static void xhci_instance_init(Object *obj)
{
XHCIPciState *s = XHCI_PCI(obj);
/*
 * QEMU_PCI_CAP_EXPRESS initialization does not depend on QEMU command
 * line, therefore, no need to wait to realize like other devices
 */
PCI_DEVICE(obj)->cap_present |= QEMU_PCI_CAP_EXPRESS;
(2) object_initialize_child(obj, "xhci-core", >xhci, TYPE_XHCI);
qdev_alias_all_properties(DEVICE(>xhci), obj);
}

The .instance_init() method initializes the child as it should, at (2).

static void usb_xhci_pci_realize(struct PCIDevice *dev, Error **errp)
{
int ret;
Error *err = NULL;
XHCIPciState *s = XHCI_PCI(dev);

[a few dev->config[] modifications...]

(1) object_property_set_link(OBJECT(>xhci), "host", OBJECT(s), NULL);
s->xhci.intr_update = xhci_pci_intr_update;
s->xhci.intr_raise = xhci_pci_intr_raise;
(2) object_property_set_bool(OBJECT(>xhci), "realized", true, );
if (err) {
error_propagate(errp, err);
return;
}

The .realize() method realizes the child at (1).  It should use
qdev_realize() like we do everywhere else, since commit ce189ab230
"qdev: Convert bus-less devices to qdev_realize() with Coccinelle".

It sets a link property from the child back to the parent at (2).  Why
do we need a link?  Each QOM Object contains a pointer to its parent,
doesn't it?

Same for xhci_sysbus_realize().