Re: [Qemu-devel] [PATCH 1/2] QMP: Introduce commands doc

[Avi Kivity]

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