Paolo Bonzini writes:
> On 19/03/20 08:01, Markus Armbruster wrote:
>> Paolo Bonzini 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 li
On 19/03/20 08:01, Markus Armbruster wrote:
> Paolo Bonzini 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()
>>> vi
Paolo Bonzini 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 sub
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 l
Paolo Bonzini writes:
> 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 +
>> finaliz
On Wed, 18 Mar 2020 at 13:22, Paolo Bonzini wrote:
> 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 "
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 bef
Paolo Bonzini writes:
> On 16/03/20 07:03, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> On 15/03/20 15:56, Markus Armbruster wrote:
>
> The question is why they are not, i.e. where does the above reasoning
> break.
I don't know. But let's for the sake of the argum
On 16/03/20 07:03, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 15/03/20 15:56, Markus Armbruster wrote:
The question is why they are not, i.e. where does the above reasoning
break.
>>> I don't know. But let's for the sake of the argument assume this
>>> actually work
Paolo Bonzini writes:
> On 15/03/20 15:56, Markus Armbruster wrote:
>>>
>>> The question is why they are not, i.e. where does the above reasoning break.
>> I don't know. But let's for the sake of the argument assume this
>> actually worked. Asking for help in the monitor then *still* has side
>
On 15/03/20 15:56, Markus Armbruster wrote:
>>
>> The question is why they are not, i.e. where does the above reasoning break.
> I don't know. But let's for the sake of the argument assume this
> actually worked. Asking for help in the monitor then *still* has side
> effects visible in the time s
Mark Cave-Ayland writes:
> On 10/03/2020 09:07, Markus Armbruster wrote:
>
>> Widespread QOM usage anti-pattern ahead; cc: QOM maintainers.
>>
>> Peter Maydell writes:
>>
>>> On Mon, 9 Mar 2020 at 10:02, Pan Nengyuan wrote:
On 3/9/2020 5:21 PM, Peter Maydell wrote:
> Could you explai
Paolo Bonzini writes:
> On 14/03/20 14:19, Mark Cave-Ayland wrote:
>>> Observe that mac_via_init() has obvious side effects. In particular, it
>>> creates two devices that are then visible in "info qtree", and that's
>>> caught by device-introspect-test.
>>>
>>> I believe these things need to be
On 14/03/20 14:19, Mark Cave-Ayland wrote:
>> Observe that mac_via_init() has obvious side effects. In particular, it
>> creates two devices that are then visible in "info qtree", and that's
>> caught by device-introspect-test.
>>
>> I believe these things need to be done in .realize().
That is n
On 10/03/2020 09:07, Markus Armbruster wrote:
> Widespread QOM usage anti-pattern ahead; cc: QOM maintainers.
>
> Peter Maydell writes:
>
>> On Mon, 9 Mar 2020 at 10:02, Pan Nengyuan wrote:
>>> On 3/9/2020 5:21 PM, Peter Maydell wrote:
Could you explain more? My thought is that we should
On Tue, 10 Mar 2020, Markus Armbruster wrote:
Root cause of this issue: nobody knows how to use QOM correctly (first
order approximation). In particular, people are perenially confused on
how to split work between .instance_init() and .realize(). We really,
really, really need to provide some g
On Tue, 10 Mar 2020 at 09:08, Markus Armbruster wrote:
> We have >200 calls of sysbus_init_child_obj() in some 40 files. I'm
> arbitrarily picking hw/arm/allwinner-a10.c for a closer look.
>
> It calls it from device allwinner-a10's .instance_init() method
> aw_a10_init(). Side effect, clearly w
Widespread QOM usage anti-pattern ahead; cc: QOM maintainers.
Peter Maydell writes:
> On Mon, 9 Mar 2020 at 10:02, Pan Nengyuan wrote:
>> On 3/9/2020 5:21 PM, Peter Maydell wrote:
>> > Could you explain more? My thought is that we should be using
>> > sysbus_init_child_obj() and we should be do
On 3/10/2020 12:16 AM, Mark Cave-Ayland wrote:
> On 09/03/2020 14:14, Markus Armbruster wrote:
>
>> Pan Nengyuan writes:
>>
>>> On 3/9/2020 8:34 PM, Markus Armbruster wrote:
Peter Maydell writes:
> On Mon, 9 Mar 2020 at 10:02, Pan Nengyuan wrote:
>> On 3/9/2020 5:21 PM, Pet
On 09/03/2020 14:14, Markus Armbruster wrote:
> Pan Nengyuan writes:
>
>> On 3/9/2020 8:34 PM, Markus Armbruster wrote:
>>> Peter Maydell writes:
>>>
On Mon, 9 Mar 2020 at 10:02, Pan Nengyuan wrote:
> On 3/9/2020 5:21 PM, Peter Maydell wrote:
>> Could you explain more? My thought
Pan Nengyuan writes:
> On 3/9/2020 8:34 PM, Markus Armbruster wrote:
>> Peter Maydell writes:
>>
>>> On Mon, 9 Mar 2020 at 10:02, Pan Nengyuan wrote:
On 3/9/2020 5:21 PM, Peter Maydell wrote:
> Could you explain more? My thought is that we should be using
> sysbus_init_child_obj()
On 3/9/2020 8:34 PM, Markus Armbruster wrote:
> Peter Maydell writes:
>
>> On Mon, 9 Mar 2020 at 10:02, Pan Nengyuan wrote:
>>> On 3/9/2020 5:21 PM, Peter Maydell wrote:
Could you explain more? My thought is that we should be using
sysbus_init_child_obj() and we should be doing it i
Peter Maydell writes:
> On Mon, 9 Mar 2020 at 10:02, Pan Nengyuan wrote:
>> On 3/9/2020 5:21 PM, Peter Maydell wrote:
>> > Could you explain more? My thought is that we should be using
>> > sysbus_init_child_obj() and we should be doing it in the init method.
>> > Why does that break the tests ?
On Mon, 9 Mar 2020 at 10:02, Pan Nengyuan wrote:
> On 3/9/2020 5:21 PM, Peter Maydell wrote:
> > Could you explain more? My thought is that we should be using
> > sysbus_init_child_obj() and we should be doing it in the init method.
> > Why does that break the tests ? It's the same thing various o
On 3/9/2020 5:21 PM, Peter Maydell wrote:
> On Mon, 9 Mar 2020 at 00:56, Pan Nengyuan wrote:
>>
>>
>>
>> On 3/8/2020 9:29 PM, Peter Maydell wrote:
>>> On Thu, 5 Mar 2020 at 06:39, Pan Nengyuan wrote:
-/* Init VIAs 1 and 2 */
-sysbus_init_child_obj(OBJECT(dev), "via1", &m->mos
On Mon, 9 Mar 2020 at 00:56, Pan Nengyuan wrote:
>
>
>
> On 3/8/2020 9:29 PM, Peter Maydell wrote:
> > On Thu, 5 Mar 2020 at 06:39, Pan Nengyuan wrote:
> >> -/* Init VIAs 1 and 2 */
> >> -sysbus_init_child_obj(OBJECT(dev), "via1", &m->mos6522_via1,
> >> - sizeof(m
On 3/8/2020 9:29 PM, Peter Maydell wrote:
> On Thu, 5 Mar 2020 at 06:39, Pan Nengyuan wrote:
>>
>> This patch fix a bug in mac_via where it failed to actually realize devices
>> it was using.
>> And move the init codes which inits the mos6522 objects and properties on
>> them from realize()
>
On Thu, 5 Mar 2020 at 06:39, Pan Nengyuan wrote:
>
> This patch fix a bug in mac_via where it failed to actually realize devices
> it was using.
> And move the init codes which inits the mos6522 objects and properties on
> them from realize()
> into init(). However, we keep qdev_set_parent_bus i
On 3/5/2020 2:54 PM, Pan Nengyuan wrote:
> This patch fix a bug in mac_via where it failed to actually realize devices
> it was using.
> And move the init codes which inits the mos6522 objects and properties on
> them from realize()
> into init(). However, we keep qdev_set_parent_bus in realiz
On 3/5/2020 2:54 PM, Pan Nengyuan wrote:
> This patch fix a bug in mac_via where it failed to actually realize devices
> it was using.
> And move the init codes which inits the mos6522 objects and properties on
> them from realize()
> into init(). However, we keep qdev_set_parent_bus in realiz
30 matches
Mail list logo
