On Tue, 24 Feb 2026 at 09:48, Daniel P. Berrangé <[email protected]> wrote:
> IMHO, it is slightly more subtle - people believe they are already
> adding children.
>
> Consider this code.
>
>     port92 = isa_create_simple(isa_bus, TYPE_PORT92);
>
> my reading of that is that I'm creating a "port92" device that is a
> child of "isa_bus". Why would I need to tell QEMU that it is a child
> for a second time ?
>
> If I trace calls through isa_create_simple I get to a call to:
>
>    qdev_realize_and_unref(dev, parent, errp);
>
> and once I again I'm left wondering why I would need to tell
> QEMU 'dev' is a child of 'parent' a second time.
>
> Of course I know the answer. We need to give a name for the
> child and it isn't trivial to "do the right thing" to invent
> an automatic name.
>
> Still, overall I'm inclined to largely blame our API designs for
> not guiding people into doing the right thing.
>
>
> Picking another random unattached set of objects "smbus-eeprom"
> I again find they've being created with qdev_realize_and_unref.
>
> Pick another unattached device 'i8259_init_chip', and again
> we end up calling into qdev_realize_and_unref()
>
>
> It feels like qdev_realize_and_unref() is a common point of
> blame in unattached devices. IMHO it ought to be taking a
> "const char *name" parameter.

I think that is because this is the function that is used
in older code that predates the "everything should be in
the QOM tree" model. Newer code doesn't use it, I think;
and it's not surprising that old pre-QOM code doesn't do
anything to put objects into the QOM tree.

The two patterns are:

 dev = qdev_new(...);
 ...
 qdev_realize_and_unref(dev, bus, errp);

and

 object_initialize_child(...);
 ...
 qdev_realize(dev, bus, errp);

This also is somewhat tangled up with the question of whether you want:

 * call a function which allocates memory and initializes it
   with an object of this type
 * I have the memory here, init the object in-place

If we could come to a definite conclusion on what we want then
we would probably be in a better position to try to enforce it.

thanks
-- PMM

Reply via email to