qemu-devel
[Top][All Lists]
Advanced

[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: Wed, 18 Mar 2020 14:21:56 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 18/03/20 14:02, Markus Armbruster wrote:
> Object instantiation must be completely reverted by finalization.
> 
> device-introspect-test guards against a particularly egregious violation
> of this rule, namely output of "info qtree" after initialization +
> finalization differing from output before.  Surprisingly common issue.
> It's what made Peter invite me to this thread.
> 
> Device realization must be completely reverted by unrealization.

So far so good.

> We don't always implement unrealize.  Fine when the device cannot be
> unrealized.  But the code doesn't seem to guard against omitting
> unrealize when the device actually can be unrealized.
> 
> Properties for use with device_add must exist after object
> instantiation.
> 
> But is that true?  Setting a property can run arbitrary code.  What if
> setting property P to value V runs code that adds property Q?  Then
> device_add P=V,Q=W works provided P gets set before Q, which is
> anybody's guess.
> 
> So "must exist" is actually "should exist", and we' already moved from
> the self-evident to the unclear.

Right, and there is already one case where the properties don't exist,
namely the "fake array" properties.

> Even less clear: what side effects may be visible between object
> initialization and realization / finalization?
> 
> A safe but constricting answer would be "only host resource
> reservation".
> 
> What's your answer?

Here are some random thoughts about it:

- object initialization should cause no side effects outside the subtree
of the object

- setting properties can cause side effects outside the subtree of the
object (e.g. marking an object as "in use"), but they must be undone by
finalization.

- 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).

Paolo




reply via email to

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