Paolo Bonzini <pbonz...@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.
