From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38089 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHisX-0003Ut-Vj for qemu-devel@nongnu.org; Thu, 27 May 2010 15:36:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHisW-0003Lj-Dj for qemu-devel@nongnu.org; Thu, 27 May 2010 15:36:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19489) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHisW-0003Lb-7R for qemu-devel@nongnu.org; Thu, 27 May 2010 15:36:28 -0400 Date: Thu, 27 May 2010 16:36:18 -0300 From: Luiz Capitulino Message-ID: <20100527163618.2fcd95a8@redhat.com> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v3 06/17] qdev: Allow device specification by qtree path for device_del List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Anthony Liguori , Juan Quintela , Markus@gnu.org, qemu-devel@nongnu.org, Armbruster , Blue Swirl , Avi Kivity , Jan Kiszka On Sun, 23 May 2010 12:59:19 +0200 Jan Kiszka wrote: > From: Jan Kiszka > > Allow to specify the device to be removed via device_del not only by ID > but also by its full or abbreviated qtree path. For this purpose, > qdev_find is introduced which combines walking the qtree with searching > for device IDs if required. [...] > Arguments: > > -- "id": the device's ID (json-string) > +- "path": the device's qtree path or unique ID (json-string) > > Example: > > --> { "execute": "device_del", "arguments": { "id": "net1" } } > +-> { "execute": "device_del", "arguments": { "path": "net1" } } Doesn't seem like a good change to me, besides being incompatible[1] we shouldn't overload arguments this way in QMP as overloading leads to interface degradation (harder to use, understand, maintain). Maybe we could have both arguments as optional, but one must be passed. [1] It's 'legal' to break the protocol before 0.13, but this has to be coordinated with libvirt so we should have a good reason to do this > <- { "return": {} } > > EQMP