[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paolo Bonzini
Subject: Re: [PATCH v4 2/3] mac_via: fix incorrect creation of mos6522 device in mac_via
Date: Thu, 19 Mar 2020 09:43:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]