From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32893) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWlXD-0001NG-KO for qemu-devel@nongnu.org; Tue, 01 Sep 2015 09:23:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWlX9-0004cv-Vk for qemu-devel@nongnu.org; Tue, 01 Sep 2015 09:23:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58969) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWlX9-0004co-O5 for qemu-devel@nongnu.org; Tue, 01 Sep 2015 09:23:31 -0400 Date: Tue, 1 Sep 2015 14:23:27 +0100 From: "Daniel P. Berrange" Message-ID: <20150901132327.GD6860@redhat.com> References: <1441101059-14269-1-git-send-email-berrange@redhat.com> <55E5A569.3030603@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55E5A569.3030603@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3] monitor: allow object_del & device_del to accept QOM paths Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: qemu-devel@nongnu.org, Markus Armbruster , Programmingkid , Gonglei , Paolo Bonzini On Tue, Sep 01, 2015 at 03:17:29PM +0200, Andreas F=C3=A4rber wrote: > 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. >=20 > Have you considered using two alternative parameters, id and qom-path? > (qom_path was used elsewhere) I'm not fussed either way, but I thought it simpler to not try to change the accepted parameters of the existing commands. Looking, the only place I notice that uses a 'qom_path' is the return data in the CpuInfo struct. Does anyone have strong feelings either way about use of id for both vs qom-path or id ? Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|