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
