Re: sysbus_create_simple Vs qdev_create

[Paolo Bonzini]

On 21/07/20 08:00, Markus Armbruster wrote:
>> They are already mirrored as links, and guess what's the link
>> name: "child[...]".
> You're right, except for the link name: it's parent_bus.

There's links in both directions.

> So the qtree is actually embedded in the QOM graph: it's the device and
> bus nodes connected by the child edges from device to provided bus and
> parent_bus link egdes from device to bus it's plugged into, except the
> latter are backward rather than forward.
> 
> Strange: even bus-less devices have this parent_bus link, and its value
> is "" (the underlying pointer is null, and null gets mapped to "", for
> better or worse).
> 
> Should the property be limited to devices that actually have a parent
> bus?

Yes, it could be done.

>>> I don't know why the rebase of qdev onto QOM was done that way.  Perhaps
>>> Paolo remembers.
>> I'm guessing this is because QOM parent/child relationships
>> represent ownership, while there's no ownership relationship
>> between buses and devices.
>
> Plausible.  I guess the separate qtree was kept even though it's
> redundant with the QOM graph because switching its users to the QOM
> graph would be work.

No, it was kept because:

1) the QOM graph wasn't embedding the qdev tree at the time.  That was
added later.

2) the composition tree generally mirrors things that are born and die
at the same time, and creating children is generally reserved to the
object itself.  Children are usually embedded directly in a struct, for
example.  Instead, peripherals are not created by the bus, they are
created by the device_add monitor command and the like.

3) accessing the QOM graph is slow (it requires hash table lookups,
string comparisons and all that), so the pointers that cache the
parent-child links are needed for use in hot paths.