qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	libvir-list@redhat.com, "Stefan Hajnoczi" <stefanha@gmail.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	qemu-devel@nongnu.org, "Gerd Hoffmann" <kraxel@redhat.com>,
	"Luiz Capitulino" <lcapitulino@redhat.com>,
	Andreas =?utf-8?Q?F=C3=A4rber?= <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH v8 2/3] qom: pass original path to unparent method
Date: Mon, 18 Mar 2013 16:03:28 +0100	[thread overview]
Message-ID: <51472CC0.8010706@redhat.com> (raw)
In-Reply-To: <87zjy0946n.fsf@codemonkey.ws>

Il 18/03/2013 15:24, Anthony Liguori ha scritto:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
>> We need to know the original path since unparenting loses this state.
>>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> ---
>>  hw/qdev.c            | 4 ++--
>>  include/qom/object.h | 3 ++-
>>  qom/object.c         | 4 +++-
>>  3 files changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/hw/qdev.c b/hw/qdev.c
>> index 741af96..64546cf 100644
>> --- a/hw/qdev.c
>> +++ b/hw/qdev.c
>> @@ -436,7 +436,7 @@ static void qbus_realize(BusState *bus, DeviceState *parent, const char *name)
>>      }
>>  }
>>  
>> -static void bus_unparent(Object *obj)
>> +static void bus_unparent(Object *obj, const char *path)
>>  {
>>      BusState *bus = BUS(obj);
>>      BusChild *kid;
>> @@ -756,7 +756,7 @@ static void device_class_base_init(ObjectClass *class, void *data)
>>      klass->props = NULL;
>>  }
>>  
>> -static void device_unparent(Object *obj)
>> +static void device_unparent(Object *obj, const char *path)
>>  {
>>      DeviceState *dev = DEVICE(obj);
>>      DeviceClass *dc = DEVICE_GET_CLASS(dev);
>> diff --git a/include/qom/object.h b/include/qom/object.h
>> index cf094e7..f0790d4 100644
>> --- a/include/qom/object.h
>> +++ b/include/qom/object.h
>> @@ -330,11 +330,12 @@ typedef struct ObjectProperty
>>  /**
>>   * ObjectUnparent:
>>   * @obj: the object that is being removed from the composition tree
>> + * @path: canonical path that object had if any
>>   *
>>   * Called when an object is being removed from the QOM composition tree.
>>   * The function should remove any backlinks from children objects to @obj.
>>   */
>> -typedef void (ObjectUnparent)(Object *obj);
>> +typedef void (ObjectUnparent)(Object *obj, const char *path);
>>  
>>  /**
>>   * ObjectFree:
>> diff --git a/qom/object.c b/qom/object.c
>> index 3d638ff..21c9da4 100644
>> --- a/qom/object.c
>> +++ b/qom/object.c
>> @@ -362,14 +362,16 @@ static void object_property_del_child(Object *obj, Object *child, Error **errp)
>>  
>>  void object_unparent(Object *obj)
>>  {
>> +    gchar *path = object_get_canonical_path(obj);
>>      object_ref(obj);
>>      if (obj->parent) {
>>          object_property_del_child(obj->parent, obj, NULL);
>>      }
>>      if (obj->class->unparent) {
>> -        (obj->class->unparent)(obj);
>> +        (obj->class->unparent)(obj, path);
>>      }
> 
> I think you should actually just move this call above
> if (obj->parent) { object_parent_del_child(...); }.
> 
> There's no harm AFAICT in doing this and it seems more logical to me to
> have destruction flow start with the subclass and move up to the base
> class.
> 
> This avoids needing a hack like this because the object is still in a
> reasonable state when unparent is called.
> 
> Paolo, do you see anything wrong with this?  I looked at the commit you
> added this in and it doesn't look like it would be a problem.

Yes, seems okay.  Especially if you think of object_property_del_child
as the base class's implementation of unparent.

Paolo

  parent reply	other threads:[~2013-03-18 15:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-14 12:40 [Qemu-devel] [PATCH v8 0/3] DEVICE_DELETED event Michael S. Tsirkin
2013-03-14 12:40 ` [Qemu-devel] [PATCH v8 1/3] qdev: " Michael S. Tsirkin
2013-03-14 12:40 ` [Qemu-devel] [PATCH v8 2/3] qom: pass original path to unparent method Michael S. Tsirkin
2013-03-18 14:24   ` Anthony Liguori
2013-03-18 14:35     ` Michael S. Tsirkin
2013-03-18 15:08       ` Paolo Bonzini
2013-03-18 15:03     ` Paolo Bonzini [this message]
2013-03-18 16:04       ` Anthony Liguori
2013-03-14 12:40 ` [Qemu-devel] [PATCH v8 3/3] qmp: add path to device_deleted event Michael S. Tsirkin
2013-03-14 14:18 ` [Qemu-devel] [PATCH v8 0/3] DEVICE_DELETED event Markus Armbruster
2013-03-14 22:56 ` [Qemu-devel] [libvirt] " Eric Blake

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=51472CC0.8010706@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=afaerber@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=armbru@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /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).