From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56560) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YanXg-0001F7-22 for qemu-devel@nongnu.org; Wed, 25 Mar 2015 11:48:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YanXa-0003IF-7g for qemu-devel@nongnu.org; Wed, 25 Mar 2015 11:48:27 -0400 Received: from smtp2.provo.novell.com ([137.65.250.81]:57700) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YanXa-0003Hz-0U for qemu-devel@nongnu.org; Wed, 25 Mar 2015 11:48:22 -0400 Message-ID: <5512D8A2.3030100@suse.com> Date: Wed, 25 Mar 2015 23:47:46 +0800 From: Lin Ma 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> In-Reply-To: <20150323143051.4cab2004@nial.brq.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 1/2] object: Add can_be_deleted callback to TypeInfo and TypeImpl Reply-To: lma@suse.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov , afaerber@suse.de, peter.crosthwaite@xilinx.com, pbonzini@redhat.com Cc: qemu-devel@nongnu.org 在 2015年03月23日 21:30, Igor Mammedov 写道: > On Mon, 23 Mar 2015 14:13:07 +0100 > Andreas Färber wrote: > >> Hi, >> >> For consistency in git-log, please use "qom:" rather than "object:". >> >> 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 however >>>> 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 allow >> to delete non-UserCreatable objects? Then it wouldn't help much. > object_del() works only with /objects children, and so far the only way > that child placed there is via object_add() which requires a new object > 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 struct ObjectClass in object.h 2. Call the function in qmp_object_del of qmp.c, says: ObjectClass *obj_class = 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 *data) { ...... oc->can_be_deleted = host_memory_backend_can_be_deleted; } > >>> Alternatively... >>> >>>> But is a better way to do this to add error handling to >>>> object_unparent API and override object_unparent for your device in >>>> question to throw the error? Then your change doesn't have to be >>>> limited to QMP. >>> ... this is also a good choice. >> Well, I have doubts about asking someone who's not ultimately familiar >> with that code to refactor the API. For instance, we wouldn't want QEMU >> on shutdown or in error cases refusing to unparent some object. >> >> Doing it at QMP level (ObjectClass/UserCreatable) seems safer, given >> that Chun Yan's trivial block option fix ended up respinning a QemuOpts >> refactoring some twenty times before it got merged. >> >> Regards, >> Andreas >> > >