[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sysbus_create_simple Vs qdev_create
From: |
Markus Armbruster |
Subject: |
Re: sysbus_create_simple Vs qdev_create |
Date: |
Wed, 29 Jul 2020 15:18:38 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Paolo Bonzini <pbonzini@redhat.com> writes:
> 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.
QOM relies on QAPI visitors to access properties. There is no
integration with the QAPI schema.
Going through a visitor enables property access from QMP, HMP and CLI.
Access from C *also* goes through a visitor. We typically go from C
type to QObject and back. Comically inefficient (which hardly matters),
verbose to use and somewhat hard to understand (which does).
Compare to what QOM replaced: qdev. Properties are a layer on top of
ordinary C. From C, you can either use the C layer (struct members,
basically), or the property layer for C (functions taking C types, no
conversion to string and back under the hood), or the "text" layer
(parse from text / format to text).
My point is not that qdev was great and QOM is terrible. There are
reasons we replaced qdev with QOM. My point is QOM doesn't *have* to be
the way it is. It is the way it is because we made it so.
>> 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.
I've long had the nagging feeling that if we had special-cased
containers, children and links, we could have made a QOM that was easier
to reason about, and much easier to integrate with a QAPI schema.
- Re: sysbus_create_simple Vs qdev_create, (continued)
- Re: sysbus_create_simple Vs qdev_create, Markus Armbruster, 2020/07/20
- Re: sysbus_create_simple Vs qdev_create, Eduardo Habkost, 2020/07/20
- Re: sysbus_create_simple Vs qdev_create, Markus Armbruster, 2020/07/21
- Re: sysbus_create_simple Vs qdev_create, Paolo Bonzini, 2020/07/27
- Re: sysbus_create_simple Vs qdev_create, Markus Armbruster, 2020/07/28
- Re: sysbus_create_simple Vs qdev_create, Paolo Bonzini, 2020/07/28
- Re: sysbus_create_simple Vs qdev_create, Eduardo Habkost, 2020/07/28
- Re: sysbus_create_simple Vs qdev_create, Paolo Bonzini, 2020/07/29
- Re: sysbus_create_simple Vs qdev_create,
Markus Armbruster <=
- Re: sysbus_create_simple Vs qdev_create, Paolo Bonzini, 2020/07/29
- Re: sysbus_create_simple Vs qdev_create, Markus Armbruster, 2020/07/30
- Re: sysbus_create_simple Vs qdev_create, Paolo Bonzini, 2020/07/30
- Re: sysbus_create_simple Vs qdev_create, Markus Armbruster, 2020/07/30
- Re: sysbus_create_simple Vs qdev_create, Paolo Bonzini, 2020/07/30
- Re: sysbus_create_simple Vs qdev_create, Eduardo Habkost, 2020/07/29
- Re: sysbus_create_simple Vs qdev_create, Paolo Bonzini, 2020/07/29
- Re: sysbus_create_simple Vs qdev_create, Eduardo Habkost, 2020/07/29
- Re: sysbus_create_simple Vs qdev_create, Paolo Bonzini, 2020/07/29
- Re: sysbus_create_simple Vs qdev_create, Markus Armbruster, 2020/07/29