On 19/03/20 08:01, Markus Armbruster wrote: > Paolo Bonzini <pbonz...@redhat.com> writes: > >> On 18/03/20 16:06, Markus Armbruster wrote: >>>> - object initialization should cause no side effects outside the subtree >>>> of the object >>> >>> object_initialize_child() and its users like sysbus_init_child_obj() >>> violate this rule: they add a child property to the subtree's parent. >>> Correct? >> >> At least object_initialize_child() adds the property to the object >> itself, so it's fine. > > It seems to > > 1. Initialize @childobj > 2. Set a bunch of properties > 3. Add the child property to @parentobj > 4. Call .complete() if it's a TYPE_USER_CREATABLE > 5. Adjust reference count > > Step 3. modifies outside the sub-tree rooted at @childobj. What am I > missing? > > Hmm, maybe this: using object_initialize_child() when initializing > @parentobj is fine; while object_initialize_child() leaves the sub-tree > rooted at @childobj, it still stays within the sub-tree rooted at > @parentobj. > > If this is how the function must be used, its contract should spell it > out!
Yes, this is what I meant. >>>> - realization can also cause side effects outside the subtree of the >>>> object, but if unrealization is possible, they must be undone by >>>> unrealization. if an object is realized and unrealization is not >>>> possible, finalization will never run (and in that case, side effects of >>>> realization need not be undone at all). >>> >>> One possible answer the question what should be done in realize() is >>> whatever must not be done earlier. Is that the best we can do? >> >> That's the lower bound of descriptivity. The upper bound is anything >> that is visible from the guest. The truth could be in the middle. > > Can we set aside a bit of time to write docs/devel/qom.rst together? I > know object.h is lovingly commented, but unless you already know how QOM > works, you're drowning in detail there. You'd have to provide most of > the contents, I'm afraid, because you know so much more about it. Could > save you time in the long run, though: fewer questions to answer, fewer > mistakes to correct. Yes, this is sorely needed. I will do it; if you have more random questions you'd like an answer for, that can help. I can then stitch them together in a coherent text. Paolo
