Re: [PATCH v4 2/3] mac_via: fix incorrect creation of mos6522 device in mac_via

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> On 19/03/20 08:01, Markus Armbruster wrote:
>> Paolo Bonzini <address@hidden> 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.

A year ago, we discussed QOM interfaces:

    Subject: Issues around TYPE_INTERFACE
    Message-ID: <address@hidden>

We touched naming conventions, the fact that interfaces can't have
state, how an interface type should be defined (even though it has no
state), and what it means to convert to such a type.

I'd love to see this covered in qom.rst.