From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60720 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHzr2-0001pC-NN for qemu-devel@nongnu.org; Fri, 28 May 2010 09:44:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHzr0-0001in-HE for qemu-devel@nongnu.org; Fri, 28 May 2010 09:44:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42337) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHzr0-0001ib-9J for qemu-devel@nongnu.org; Fri, 28 May 2010 09:44:02 -0400 Date: Fri, 28 May 2010 10:43:49 -0300 From: Luiz Capitulino Message-ID: <20100528104349.5e468336@redhat.com> In-Reply-To: <4BFEF004.90800@web.de> References: <20100527163618.2fcd95a8@redhat.com> <4BFEF004.90800@web.de> 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 Fri, 28 May 2010 00:19:48 +0200 Jan Kiszka wrote: > Luiz Capitulino wrote: > > 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). > > It's not overloaded, think of an ID as a (weak) symbolic link in the > qtree filesystem. The advantage of basing everything on top of full or > abbreviated qtree paths is that IDs are not always assigned, paths are. You mean there're cases where an ID is not assigned? I didn't know that, I thought they were always assigned, at least via QMP. In any case, my main question here is that if this change really makes sense for QMP or if it's something for HMP where we can have features like tab completion. > > Maybe we could have both arguments as optional, but one must be passed. > > This would at least require some way to keep the proposed unified path > specification for the human monitor (having separate arguments there is > really unhandy). Agreed, perhaps we have to decouple QMP and HMP in the way proposed by Anthony: the HMP should work by making QMP calls (IIUC). This way HMP can accept whatever arguments make sense for it, but then it should transform them in a QMP call. This is a long term project though.