From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33728 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCZyl-0005tX-A9 for qemu-devel@nongnu.org; Thu, 13 May 2010 11:05:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCZyj-0005qc-3w for qemu-devel@nongnu.org; Thu, 13 May 2010 11:05:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46290) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCZyi-0005qR-Sw for qemu-devel@nongnu.org; Thu, 13 May 2010 11:05:37 -0400 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 o4DF5YSB005169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 May 2010 11:05:34 -0400 Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com [10.35.255.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o4DF5XPu015179 for ; Thu, 13 May 2010 11:05:33 -0400 Message-ID: <4BEC153C.7040600@redhat.com> Date: Thu, 13 May 2010 18:05:32 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/2] QMP: Introduce commands doc References: <1273086712-29163-1-git-send-email-lcapitulino@redhat.com> <1273086712-29163-2-git-send-email-lcapitulino@redhat.com> <4BEC031D.6020506@redhat.com> <20100513115524.29f826a0@redhat.com> In-Reply-To: <20100513115524.29f826a0@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: bazulay@redhat.com, juzhang@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com On 05/13/2010 05:55 PM, Luiz Capitulino wrote: > > >>> +change >>> +------ >>> + >>> +Change a removable medium or VNC configuration. >>> >>> >> This is sad. Would anyone write a C function with a similar description? >> > I wouldn't, but someone did for qemu. > > >> Do we have this in 0.12? If not we can change (...) it. If we do, it's >> a more difficult deprecation process. >> > Yes, we do and it's used by libvirt iirc. > I see. Perhaps we can have change-storage and change-vnc, and deprecate the multiplexer. >>> +cpu >>> +--- >>> + >>> +Set the default CPU. >>> + >>> +Arguments: >>> + >>> +- "index": the CPU's index (json-int) >>> + >>> +Example: >>> + >>> +{ "execute": "cpu", "arguments": { "index": 0 } } >>> + >>> +Note: CPUs' indexes are obtained with the 'query-cpus' command. >>> >>> >> The default cpu is local to the monitor? >> > I guess so, someone has reported to me that QMP's and user Monitor's > behavior diverge. Ie, the default cpu set in QMP doesn't show up as > default in the user Monitor. > That's because it's local: each monitor has its own default cpu: > > struct Monitor { > ... > CPUState *mon_cpu; This needs to be documented. >>> + >>> +migrate >>> +------- >>> + >>> +Migrate to URI. >>> + >>> +Arguments: >>> + >>> +- "blk": block migration, full disk copy (json-bool, optional) >>> +- "inc": incremental disk copy (json-bool, optional) >>> >>> >> Don't these need to be per-disk? >> > You mean the documentation should say that or should we be able to > specify the disk some way? > Both (with the block-migrate implementation leading the way). It's reasonable to have one disk on shared storage and another on local storage. For example, your swap device could be local while the main disk resides on a SAN/NAS. >>> +-------- >>> + >>> +Save to disk physical memory dump starting at 'val' of size 'size'. >>> + >>> +Arguments: >>> + >>> +- "val": the starting address (json-int) >>> >>> >> Why "val" instead of "address" or "physical-address"? >> > Mea culpa, for this and most inconsistencies you find in the protocol. > > The reason is that I did a lot of conversions in a hurry, so that > we could get libvirt working under QMP as soon as possible. > > Unfortunately, some bad names and some bad behaviors from the user > Monitor leaked into QMP. Lesson learned, although sometimes it's very > difficult to define what a name/behavior should be in QMP. > That's what review is for, and since it's harder to review code, we only caught this now. > >>> +query-mice >>> +---------- >>> + >>> +Show VM mice information. >>> + >>> +Each mouse is represented by a json-object, the returned value is a json-array >>> +of all mice. >>> + >>> +The mouse json-object contains the following: >>> + >>> +- "name": mouse's name (json-string) >>> +- "index": mouse's index (json-int) >>> +- "current": true if this mouse is receiving events, false otherwise (json-bool) >>> >>> >> What does this mean? >> > It's the mouse that will move, I guess. > Perhaps the mouse that is connected to vnc or SDL. Eventually we'll need to support multiple host mice, though perhaps not in the next few years. -- error compiling committee.c: too many arguments to function