Re: sysbus_create_simple Vs qdev_create

[Paolo Bonzini]

On 29/07/20 00:47, Eduardo Habkost wrote:
> On Tue, Jul 28, 2020 at 07:38:27PM +0200, Paolo Bonzini wrote:
>> On 28/07/20 09:19, Markus Armbruster wrote:
>>>> 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.
>>>
>>> Yes.  Notable exceptions: containers /machine/peripheral,
>>> /machine/peripheral-anon, /machine/unattached.
>>
>> And /objects too.  Apart from /machine/unattached, all these dynamic
>> objects are created by the monitor or the command line.
>>
>>>>                 Children are usually embedded directly in a struct, for
>>>> example.
>>>
>>> We sometimes use object_new() + object_property_add_child() instead.
>>> Extra indirection.  I guess we'd be better off without the extra
>>> indirection most of the time.  Implementation detail.
>>>
>>> We sometimes use object_new() without object_property_add_child(), and
>>> have qdev_realize() put the device in the /machine/unattached orphanage.
>>> Meh.  I guess the orphanage feature exists to make conversion to QOM
>>> slightly easier.  Could we ban its use for new boards at least?
>>
>> Banning perhaps is too strong, but yes /machine/unattached is an
>> anti-pattern.
>>
>>>> 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.
>>>
>>> True, but only because QOM's design opts for generality, efficiency be
>>> damned :)
>>
>> Remember that QOM's essential feature is the visitors: unlike GObject,
>> QOM is not targeted at programming languages but rather at CLI and RPC.
> 
> This is surprising to me.  I never thought QOM was targeted at
> the CLI or RPC.  (Every single property mentioned in this message
> don't seem to be related to the CLI or RPC.)

See https://www.mail-archive.com/qemu-devel@nongnu.org/msg674110.html
for an explanation.

> About the visitors: I always had the impression that usage of
> visitors inside QOM is unnecessary and avoidable (compared to
> QAPI, where the visitors are an essential feature).

But as I explained in that other message, the main difference between
QOM and something like GObject is eactly the QAPI integration, and that
is where CLI and RPC enter the game: for example the possibility to
share code between -object and HMP object_add on one side and QMP
object-add on the other side.

Even code riddled by backwards-compatibility special cases, such as
-accel and -machine, can share code between themselves and -object to
some extent; this is thanks to functions such as object_property_parse,
whose parsing is deferred to visitors and hence to QAPI.

> Do we really need need QOM children to be accessible using the QOM
> property API?
> 
> Using the same code for both user-configurable properties and for
> the list of children of a QOM object might have saved some time
> years ago, but I'm not sure this is still a necessary or useful
> abstraction.

The main thing we get from it is that the QOM paths treat children and
links the same, and links are properties.  To be honest it's not a
feature that is very much developed, so perhaps we can remove it but we
need to evaluate the impact of losing it.

Paolo