From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59502) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWlRP-0007Yd-Lw for qemu-devel@nongnu.org; Tue, 01 Sep 2015 09:17:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWlRK-0000h8-NO for qemu-devel@nongnu.org; Tue, 01 Sep 2015 09:17:35 -0400 Received: from mx2.suse.de ([195.135.220.15]:50541) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWlRK-0000gW-HS for qemu-devel@nongnu.org; Tue, 01 Sep 2015 09:17:30 -0400 References: <1441101059-14269-1-git-send-email-berrange@redhat.com> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Message-ID: <55E5A569.3030603@suse.de> Date: Tue, 1 Sep 2015 15:17:29 +0200 MIME-Version: 1.0 In-Reply-To: <1441101059-14269-1-git-send-email-berrange@redhat.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3] monitor: allow object_del & device_del to accept QOM paths List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org, Eric Blake Cc: Programmingkid , Gonglei , Markus Armbruster , Paolo Bonzini Am 01.09.2015 um 11:50 schrieb Daniel P. Berrange: > Currently both object_del and device_del require that the > client provide the object/device short ID. While user > creatable objects require an ID to be provided at time of > creation, qdev devices may be created without giving an > ID. The only unique identifier they would then have is the > QOM object path. >=20 > Allowing device_del to accept an object path ensures all > devices are deletable regardless of whether they have an > ID. >=20 > (qemu) device_add usb-mouse > (qemu) qom-list /machine/peripheral-anon > device[0] (child) > type (string) > (qemu) device_del /machine/peripheral-anon/device[0] >=20 > Although objects require an ID to be provided upfront, > there may be cases where the client would prefer to > use QOM paths when deleting. >=20 > Devices are required to be marked as hotpluggable > otherwise an error is raised >=20 > (qemu) device_del /machine/unattached/device[4] > Device 'PIIX3' does not support hotplugging >=20 > Similarly objects are required to implement the > user-creatable interface >=20 > (qemu) object_del /machine/unattached/device[4] > /machine/unattached/device[4] is not a user-creatable object >=20 > Signed-off-by: Daniel P. Berrange > --- >=20 > Changed in v3: >=20 > - Add type checks to avoid assertion failures if user > supplied path is not of type device or user-creatable >=20 > hmp-commands.hx | 6 ++++-- > qapi-schema.json | 4 ++-- > qdev-monitor.c | 19 ++++++++++++++----- > qmp-commands.hx | 13 +++++++++++-- > qmp.c | 15 ++++++++++++--- > 5 files changed, 43 insertions(+), 14 deletions(-) >=20 > diff --git a/hmp-commands.hx b/hmp-commands.hx > index d3b7932..c0c113d 100644 > --- a/hmp-commands.hx > +++ b/hmp-commands.hx > @@ -675,7 +675,8 @@ ETEXI > STEXI > @item device_del @var{id} > @findex device_del > -Remove device @var{id}. > +Remove device @var{id}. @var{id} may be a short ID > +or a QOM object path. Have you considered using two alternative parameters, id and qom-path? (qom_path was used elsewhere) Regards, Andreas > ETEXI > =20 > { > @@ -1279,7 +1280,8 @@ ETEXI > STEXI > @item object_del > @findex object_del > -Destroy QOM object. > +Destroy QOM object. @var{id} may be a short ID > +or a QOM object path. > ETEXI > =20 > #ifdef CONFIG_SLIRP [snip] --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N=FC= rnberg)