qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Michael Tokarev <mjt@tls.msk.ru>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] commit da57febfed "qdev: give all devices a canonical path" broke usb_del
Date: Wed, 08 Aug 2012 15:02:25 +0200	[thread overview]
Message-ID: <50226361.8090006@redhat.com> (raw)
In-Reply-To: <50226006.6050402@suse.de>

Il 08/08/2012 14:48, Andreas Färber ha scritto:
> Adding object_unparent() to object_delete() looks okay to me, but we
> should not forget about the upcoming i440fx and prep_pci use cases where
> we want to embed children in the parent's struct, so that
> object_delete() will never be called on it. Thus object_unparent() would
> need to remain present in the deinit path, no?

object_property_del_all should take care of it for embedded objects:
- the outermost struct is deleted via object_delete
- it is unparented and unrefed, so refcount goes to 0 and finalize is called
- finalize calls object_property_del_all
- object_finalize_child_property calls unref on the nested object, so
refcount goes to 0 and finalize is called.  Things can then proceed
recursively.

It would be more complicated (and would cause memory leaks) if you got
nested objects that were allocated.  To account for this, I understood
you would need something like the following:

- you add a "void (*release)(void *obj)" member to Object.
- object_new sets the release member to g_free
- object_delete does not call g_free anymore
- object_finalize calls the release member if it is not NULL

Do you have time to implement it?

Paolo

  reply	other threads:[~2012-08-08 13:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-08 12:18 [Qemu-devel] commit da57febfed "qdev: give all devices a canonical path" broke usb_del Michael Tokarev
2012-08-08 12:22 ` Michael Tokarev
2012-08-08 12:39   ` Paolo Bonzini
2012-08-08 12:48     ` Andreas Färber
2012-08-08 13:02       ` Paolo Bonzini [this message]
2012-08-08 13:09     ` Michael Tokarev
2012-08-08 14:42       ` Michael Tokarev
2012-08-08 16:08         ` Michael Tokarev
2012-08-20 17:58         ` Anthony Liguori
2012-08-21  7:06           ` Paolo Bonzini
2012-08-21 19:53             ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50226361.8090006@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=afaerber@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=mjt@tls.msk.ru \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).