From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37109) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya2AL-0000Fk-PI for qemu-devel@nongnu.org; Mon, 23 Mar 2015 09:13:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ya2AH-0001jr-Or for qemu-devel@nongnu.org; Mon, 23 Mar 2015 09:13:13 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33952 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ya2AH-0001jm-J8 for qemu-devel@nongnu.org; Mon, 23 Mar 2015 09:13:09 -0400 Message-ID: <55101163.6050201@suse.de> Date: Mon, 23 Mar 2015 14:13:07 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1427105442-23484-1-git-send-email-lma@suse.com> <551001E3.3010304@redhat.com> In-Reply-To: <551001E3.3010304@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: Paolo Bonzini , Peter Crosthwaite , Lin Ma Cc: Igor Mammedov , "qemu-devel@nongnu.org Developers" , Bruce Rogers 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. > Alternatively... >=20 >> 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. >=20 > ... 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 --=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)