From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nd5uf-0000kj-Tz for qemu-devel@nongnu.org; Thu, 04 Feb 2010 12:54:45 -0500 Received: from [199.232.76.173] (port=46841 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nd5ue-0000kP-PY for qemu-devel@nongnu.org; Thu, 04 Feb 2010 12:54:44 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nd5uc-0002fA-GV for qemu-devel@nongnu.org; Thu, 04 Feb 2010 12:54:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32776) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nd5uc-0002f2-2D for qemu-devel@nongnu.org; Thu, 04 Feb 2010 12:54:42 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o14Hse2d031216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 4 Feb 2010 12:54:40 -0500 Date: Thu, 4 Feb 2010 17:54:38 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] Converting existing name=value,... arguments to QMP Message-ID: <20100204175438.GA17226@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org On Thu, Feb 04, 2010 at 06:43:22PM +0100, Markus Armbruster wrote: > The human monitor uses positional arguments. This is fine; nobody wants > to type "info item=network" instead of "info network". > > QMP uses named arguments. Also fine. > > Internally, we use named arguments: we pass them as QDict to the command > handler. This involves associating positional arguments with names. > Works fine. > > There's one little mess hiding in a corner, though: a few commands abuse > a positional argument to get named arguments. That argument has the > form of a "parameter string": NAME=VALUE,... For instance: > > pci_add auto nic model=e1000,macaddr=00:11:22:33:44:55 > > If we convert this naively, we get in QMP: > > { "execute": "pci_add", > "arguments": { "pci_addr": "auto", > "type": "nic", > "opts": "model=e1000,macaddr=00:11:22:33:44:55" } } > > which is silly. Oops, we already did. This isn't so silly, because it allows the mgmt apps to re-use the exact same code for generating the 'opts' string here that they already have written to generate the initial '-net' argument value when launching QEMU. That is a very big benefit that I would not like to loose > A more appropriate encoding would be > > { "execute": "pci_add", > "arguments": { "pci_addr": "auto", > "type": "nic", > "model": "e1000", > "macaddr": "00:11:22:33:44:55" } } > > or maybe > > { "execute": "pci_add", > "arguments": { "pci_addr": "auto", > "type": "nic", > "opts": { "model": "e1000", > "macaddr": "00:11:22:33:44:55" } } } Both these approaches mean extra code for client apps, by not allowing re-use of the ARGV argument generators they must already implement. That said I can see the value in allowing the "fully normalized" format, so if going for the second option, then I'd say that QEMU should use its existing key,value pair parser to automagically convert this: > "opts": "model=e1000,macaddr=00:11:22:33:44:55" } } into this > "opts": { "model": "e1000", > "macaddr": "00:11:22:33:44:55" } } } in case where it saw a JSON string, instead of hash. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|