From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37489) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yb4hK-0004cC-VR for qemu-devel@nongnu.org; Thu, 26 Mar 2015 06:07:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yb4hG-0007Kz-VA for qemu-devel@nongnu.org; Thu, 26 Mar 2015 06:07:34 -0400 Received: from cantor2.suse.de ([195.135.220.15]:53948 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yb4hG-0007KP-Hm for qemu-devel@nongnu.org; Thu, 26 Mar 2015 06:07:30 -0400 Message-ID: <5513DA5F.6060906@suse.de> Date: Thu, 26 Mar 2015 11:07:27 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1427105442-23484-1-git-send-email-lma@suse.com> <551001E3.3010304@redhat.com> <55101163.6050201@suse.de> <20150323143051.4cab2004@nial.brq.redhat.com> <5512D8A2.3030100@suse.com> <20150326110529.5f158af3@nial.brq.redhat.com> In-Reply-To: <20150326110529.5f158af3@nial.brq.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/2] object: Add can_be_deleted callback to TypeInfo and TypeImpl List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov , Lin Ma Cc: pbonzini@redhat.com, peter.crosthwaite@xilinx.com, qemu-devel@nongnu.org Am 26.03.2015 um 11:05 schrieb Igor Mammedov: > On Wed, 25 Mar 2015 23:47:46 +0800 > Lin Ma wrote: >> =E5=9C=A8 2015=E5=B9=B403=E6=9C=8823=E6=97=A5 21:30, Igor Mammedov =E5= =86=99=E9=81=93: >>> On Mon, 23 Mar 2015 14:13:07 +0100 >>> Andreas F=C3=A4rber wrote: >>>> Am 23.03.2015 um 13:06 schrieb Paolo Bonzini: >>>>> On 23/03/2015 11:36, Peter Crosthwaite wrote: >>>>>> I don't think TypeInfo is the right place for this. You can howeve= r >>>>>> define function hooks for Object in ObjectClass. See the unparent >>>>>> field of ObjectClass for a precedent. >>>> Agree. >>>> >>>>> In this case, the right place could be UserCreatable. >>>> Maybe, not so familiar with that interface myself. Does object_del a= llow >>>> to delete non-UserCreatable objects? Then it wouldn't help much. >>> object_del() works only with /objects children, and so far the only w= ay >>> that child placed there is via object_add() which requires a new obje= ct >>> to have TYPE_USER_CREATABLE interface. >>> I'd go this way rather than overhaul object_unparent() in this case. >> What about these changes? >> 1. Add a callback function named 'ObjectCanBeDeleted *can_be_deleted' = to=20 >> struct ObjectClass in object.h >> 2. Call the function in qmp_object_del of qmp.c, says: >> ObjectClass *obj_class =3D object_get_class(obj); >> if (obj_class->can_be_deleted) >> if (!obj_class->can_be_deleted(obj)) >> error out >> >> 3. Then implement can_be_deleted callback in backends, says: >> static bool host_memory_backend_can_be_deleted(Object *obj) {....= ..} >> >> static void host_memory_backend_class_init(ObjectClass *oc, void=20 >> *data) { >> ...... >> oc->can_be_deleted =3D host_memory_backend_can_be_deleted; >> } >=20 > all backends currently implement TYPE_USER_CREATABLE interface, > so I'd rather extend UserCreatableClass with: >=20 > bool can_be_deleted(UserCreatable *uc) >=20 > callback, which backends could implement if needed. As for the implementation, could we simply look at Object::ref field? Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Felix Imend=C3=B6rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=C3=BCrnberg)