From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49995) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWnzW-00045y-GU for qemu-devel@nongnu.org; Tue, 01 Sep 2015 12:01:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWnzS-00050u-3z for qemu-devel@nongnu.org; Tue, 01 Sep 2015 12:00:58 -0400 Received: from mx2.suse.de ([195.135.220.15]:33661) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWnzR-00050Y-TL for qemu-devel@nongnu.org; Tue, 01 Sep 2015 12:00:54 -0400 References: <1441101059-14269-1-git-send-email-berrange@redhat.com> <55E5A569.3030603@suse.de> <20150901132327.GD6860@redhat.com> <55E5CA66.3070200@redhat.com> <649D6DBF-36CB-4292-AAE6-C8A7454B55D0@gmail.com> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Message-ID: <55E5CBB4.6060109@suse.de> Date: Tue, 1 Sep 2015 18:00:52 +0200 MIME-Version: 1.0 In-Reply-To: <649D6DBF-36CB-4292-AAE6-C8A7454B55D0@gmail.com> Content-Type: text/plain; charset=windows-1252 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: Programmingkid Cc: qemu-devel@nongnu.org, Markus Armbruster , Gonglei , Paolo Bonzini Am 01.09.2015 um 17:58 schrieb Programmingkid: > On Sep 1, 2015, at 11:55 AM, Eric Blake wrote: >> On 09/01/2015 07:23 AM, Daniel P. Berrange wrote: >>>>> +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-pat= h? >>>> (qom_path was used elsewhere) >>> >>> I'm not fussed either way, but I thought it simpler to not try to cha= nge >>> the accepted parameters of the existing commands. Looking, the only >>> place I notice that uses a 'qom_path' is the return data in the CpuIn= fo >>> struct. >>> >>> Does anyone have strong feelings either way about use of id for both = vs >>> qom-path or id ? >> >> Reusing 'id': >> - Pros >> - less complicated interface (don't have to check for mutual exclusio= n) >> - Cons >> - not introspectible (can't tell by introspection alone whether id ca= n >> take a QOM path) >> - confusing name (but not the first time we've had that issue) >> >> Adding 'qom-path': >> - Pros >> - introspectible >> - JSON expresses everything (we don't have to parse the first >> character of the string to know which style was meant, as the choice o= f >> key already decided it) >> - Cons >> - Have to implement mutual exclusion ourselves (can't take 'id' and >> 'qom-path' at the same time, and at least one must be specified), unle= ss >> we invent a new way for qapi to express mutual exclusion (there are >> other existing commands that would benefit from such an extension) >=20 > Don't forget having a really long command to type up just to find out > what qom path you need.=20 >=20 > Also the qom path itself is very long. A simple ID is much easier to ty= pe out. That's besides the point: IDs can already be specified without this patch. This patch is shoehorning QOM paths into an existing ID argument. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N=FC= rnberg)