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. > 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. Paolo > It's makes reasoning about properties harder, and introspection brittle.
