The part of the documentation of DeviceClass that talks about instance_init
is partly wrong: instance_init() functions must not abort or exit, since
the function is also called during introspection of the device already.
So if a device calls exit() during its instance_init() function, QEMU
terminates unexpectedly if somebody tries to just have a look at the
interfaces from the device with "device_add xyz,help" or with the
"device-list-properties" QOM command. This should never happen.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 include/hw/qdev-core.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index f1fd0f8..a24d0dd 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -51,8 +51,9 @@ struct VMStateDescription;
  * Devices are constructed in two stages,
  * 1) object instantiation via object_initialize() and
  * 2) device realization via #DeviceState:realized property.
- * The former may not fail (it might assert or exit), the latter may return
- * error information to the caller and must be re-entrant.
+ * The former may not fail (and must not abort or exit, since it is called
+ * during device introspection already), and the latter may return error
+ * information to the caller and must be re-entrant.
  * Trivial field initializations should go into #TypeInfo.instance_init.
  * Operations depending on @props static properties should go into @realize.
  * After successful realization, setting static properties will fail.
-- 
1.8.3.1

Thomas Huth <thuth@redhat.com> writes:

> The part of the documentation of DeviceClass that talks about instance_init
> is partly wrong: instance_init() functions must not abort or exit, since
> the function is also called during introspection of the device already.

I figure it was correct back when the comment was written.  It's
definitely wrong now.

> So if a device calls exit() during its instance_init() function, QEMU
> terminates unexpectedly if somebody tries to just have a look at the
> interfaces from the device with "device_add xyz,help" or with the
> "device-list-properties" QOM command. This should never happen.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>

Reviewed-by: Markus Armbruster <armbru@redhat.com>

Am 10.09.18 um 10:09 schrieb Thomas Huth:
> The part of the documentation of DeviceClass that talks about instance_init
> is partly wrong: instance_init() functions must not abort or exit, since
> the function is also called during introspection of the device already.
> So if a device calls exit() during its instance_init() function, QEMU
> terminates unexpectedly if somebody tries to just have a look at the
> interfaces from the device with "device_add xyz,help" or with the
> "device-list-properties" QOM command. This should never happen.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>

Reviewed-by: Andreas Färber <afaerber@suse.de>

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

On 9/10/18 5:09 AM, Thomas Huth wrote:
> The part of the documentation of DeviceClass that talks about instance_init
> is partly wrong: instance_init() functions must not abort or exit, since
> the function is also called during introspection of the device already.
> So if a device calls exit() during its instance_init() function, QEMU
> terminates unexpectedly if somebody tries to just have a look at the
> interfaces from the device with "device_add xyz,help" or with the
> "device-list-properties" QOM command. This should never happen.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>

Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

> ---
>  include/hw/qdev-core.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> index f1fd0f8..a24d0dd 100644
> --- a/include/hw/qdev-core.h
> +++ b/include/hw/qdev-core.h
> @@ -51,8 +51,9 @@ struct VMStateDescription;
>   * Devices are constructed in two stages,
>   * 1) object instantiation via object_initialize() and
>   * 2) device realization via #DeviceState:realized property.
> - * The former may not fail (it might assert or exit), the latter may return
> - * error information to the caller and must be re-entrant.
> + * The former may not fail (and must not abort or exit, since it is called
> + * during device introspection already), and the latter may return error
> + * information to the caller and must be re-entrant.
>   * Trivial field initializations should go into #TypeInfo.instance_init.
>   * Operations depending on @props static properties should go into @realize.
>   * After successful realization, setting static properties will fail.
>