qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [RFC v0 00/15] QEMU Monitor Protocol
Date: Sun, 22 Nov 2009 13:02:15 -0200	[thread overview]
Message-ID: <20091122130215.5021843b@doriath> (raw)
In-Reply-To: <4B09072E.4090206@redhat.com>

On Sun, 22 Nov 2009 11:41:02 +0200
Avi Kivity <avi@redhat.com> wrote:

> On 11/19/2009 06:47 PM, Luiz Capitulino wrote:
> >
> >> Can you post a capture of a few monitor commands through the new protocol?
> >>      
> >   Here goes, it's a telnet session:
> >    
> 
> Looks really good, some comments below.
> 
> > """
> > {"QMP": {"capabilities": []}}
> >
> > { "execute": "info", "arguments": { "item": "balloon" } }
> > {"return": 1024}
> >    
> 
> 1. I see no id attribute, but it's supported, yes?

 Yes, it can be any json-value, like this real example:

{ "execute": "info", "arguments": { "item": "balloon" }, "id": "foobar" }
{"return": 1024, "id": "foobar"}

> 2. I asked before for info commands to be separated into individual 
> commands ("query-balloon") when in machine mode.  You wouldn't write a 
> function info(enum info_thing what), would you?  What would its return 
> type be?

 Yes, you're right.. I didn't do it yet because I was focusing in getting
the protocol working first.

 There is an easy way to support it though. We could add a check for
commands which start with query- and call do_info() with the
appropriate arguments.

 This way we get this syntax valid for the first merge and postpone the
Monitor refactoring to properly support it to 0.13.

 Actually, the Monitor needs a big refactoring and that was true
even before QMP.

> 3. Quantities, for the machine protocol, should be in natural units (in 
> this case, bytes).  The human interface can use kMGT and have some 
> reasonable default.

 Will fix.

> > { "execute": "info", "arguments": { "item": "balloon" } }
> > {"return": 512}
> >
> > { "execute": "info", "arguments": { "item": "network" } }
> > {"return": [{"devices": [{"name": "user.0", "info": "net=10.0.2.0, restricted=n"}, {"name": "e1000.0", "info": "model=e1000,macaddr=52:54:00:12:34:56"}], "id": 0}]}
> >    
> 
> The internal "info" is very worrying.  We need to make sure everything 
> is returned as an object without the need for additional parsing.

 That's the complicated part.

 Some (several?) Monitor commands would require deeper changes to return
100% of their information in QObject style.

 This takes time for me, as I have to dig in subsystems I'm not so
familiar with and have to work on the other series too.

 So, I've chosen to do the easy conversion now so that the project
goes forward. I know this can compromise protocol stability, but I was
planning not to declare the protocol stable for 0.12.

 This is a discussion we should have.

> > { "execute": "migrate", "arguments": { "detach": "-d", "uri": "tcp:localhost:4445" } }
> > {"error": {"class": "InvalidParameter", "data": {"parameter": "detach", "reason": "must be an integer"}}}
> >    
> 
> I presume true and false would work here?

 Yes, at the time I introduced QDict I couldn't foresee that.

  reply	other threads:[~2009-11-22 15:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-19 15:13 [Qemu-devel] [RFC v0 00/15] QEMU Monitor Protocol Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 01/15] monitor: Introduce MONITOR_USE_CONTROL flag Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 02/15] monitor: Command-line flag to enable control mode Luiz Capitulino
2009-11-22 18:06   ` Anthony Liguori
2009-11-19 15:13 ` [Qemu-devel] [PATCH 03/15] monitor: Move handler calling code to its own function Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 04/15] QError: Add errors used by QMP Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 05/15] QMP: chardev handling Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 06/15] QMP: Output support Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 07/15] QMP: Input support Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 08/15] QMP: Asynchronous events infrastructure Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 09/15] QMP: Introduce basic asynchronous events Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 10/15] QMP: Disable monitor print functions Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 11/15] QMP: Introduce README file Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 12/15] QMP: Introduce specification Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 13/15] QMP: Introduce qmp-events.txt Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 14/15] QMP: Introduce qmp-shell Luiz Capitulino
2009-11-19 15:13 ` [Qemu-devel] [PATCH 15/15] QMP: Introduce vm-info Luiz Capitulino
2009-11-19 15:20 ` [Qemu-devel] Re: [RFC v0 00/15] QEMU Monitor Protocol Avi Kivity
2009-11-19 16:47   ` Luiz Capitulino
2009-11-22  9:41     ` Avi Kivity
2009-11-22 15:02       ` Luiz Capitulino [this message]
2009-11-22 16:04         ` Anthony Liguori
2009-11-23 13:07           ` Luiz Capitulino
2009-11-19 17:00 ` [Qemu-devel] " Luiz Capitulino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091122130215.5021843b@doriath \
    --to=lcapitulino@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).