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.) 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). > > > I never quite understood why we need to build properties at run time. > > I think it was (for once) Anthony reasoning that good is better than > perfect. You do need run-time properties for /machine/unattached, > /machine/peripheral, etc., so he decided to only have run-time > properties. Introspection wasn't considered a primary design goal. > > Also, even though child properties are quite often the same for all > objects after initialization (and possibly realization) is complete, > this does not cover in two cases: > > 1) before the corresponding objects are created---so static child > properties would only be possible if creation of all children is moved > to instance_init, which is guaranteed not to fail. > > 2) there are cases in which a property (e.g. an int) governs how many of > those children exist, so you cannot create all children in instance_init. 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. -- Eduardo
