Re: [Qemu-devel] Object instantiation vs. device realization: what to do when?

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 14/02/19 17:21, Markus Armbruster wrote:
>>  * As an interim step, the #DeviceState:realized property can also be
>>  * set with qdev_init_nofail().
>>  * In the future, devices will propagate this state change to their children
>>  * and along busses they expose.
>> 
>> This sentence is five years old.  Any progress?  If not, any intentions
>> to make progress?
>
> Good news, it's done!  What we still don't do is removing
> qdev_init_nofail and realizing the whole machine in one fell swoop.
>
> Bad news, it's been done for five years:
>
>     commit 5c21ce77d7e5643089ceec556c0408445d017f32
>     Author: Bandan Das <bsd@redhat.com>
>     Date:   Wed Mar 12 21:02:12 2014 +0100
>
>     qdev: Realize buses on device realization
>
>     Integrate (un)realization of child buses with
>     realization/unrealization
>     of the device hosting them. Code in device_unparent() is reordered
>     for unrealization of buses to work as part of device unrealization.
>
>     That way no changes need to be made to bus instantiation.
>
>     Signed-off-by: Bandan Das <bsd@redhat.com>
>     Signed-off-by: Andreas Färber <afaerber@suse.de>
>
> so I don't expect that the next step will ever happen...

Sigh...  can you suggest an update to the comment then?

Out of curiosity, what would have to be done?  Any particular problems
other than the practical problem of manhandling 300+ qdev_init_nofail()
calls?

>>  * The point in time will be deferred to machine creation, so that values
>>  * set in @realize will not be introspectable beforehand. Therefore devices
>>  * must not create children during @realize; they should initialize them via
>>  * object_initialize() in their own #TypeInfo.instance_init and forward the
>>  * realization events appropriately.
>> 
>> This is mostly greek to me.  Pity the developer who knows less about
>> qdev than I do.
>
> The first part refers to what virtio_instance_init_common does:
>
>     object_initialize(vdev, vdev_size, vdev_name);
>     object_property_add_child(proxy_obj, "virtio-backend", OBJECT(vdev),
>                               NULL);
>     object_unref(OBJECT(vdev));
>
> The second part doesn't apply to virtio because it has a bus (so the
> code from the above commit handles recursive realization automatically).
>
> hw/sd/milkymist-memcard.c has an example of this:
>
>     object_property_set_bool(OBJECT(carddev), true, "realized", &err);
>
> but it should create the device in milkymist_memcard_init rather than
> milkymist_memcard_realize, in order to obey the directives of the sacred
> book of QEMU.

I see.

Thanks!