[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: ANN: QEMU Monitor Protocol git tree
From: |
Michael S. Tsirkin |
Subject: |
[Qemu-devel] Re: ANN: QEMU Monitor Protocol git tree |
Date: |
Wed, 11 Nov 2009 12:03:25 +0200 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
On Thu, Sep 24, 2009 at 03:28:40PM +0200, Markus Armbruster wrote:
> Luiz Capitulino <address@hidden> writes:
>
> > On Thu, 24 Sep 2009 00:37:53 +0200
> > Markus Armbruster <address@hidden> wrote:
> >
> >> Luiz Capitulino <address@hidden> writes:
> >>
> >> [...]
> >> > 2.2 Server Greeting
> >> > -------------------
> >> >
> >> > Right when connected the Server will issue a greeting message, which
> >> > signals
> >> > that the connection has been successfully established and that the
> >> > Server is
> >> > waiting for commands.
> >> >
> >> > The format is:
> >> >
> >> > { "QEMU": json-string, "QMP": json-string, "capabilities": json-array }
> >> >
> >> > Where,
> >> >
> >> > - The "QEMU" member contains the QEMU version
> >> > - The "QMP" member contains the QMP version
> >> > - The "capabilities" member specify the availability of features beyond
> >> > the
> >> > baseline specification
> >>
> >> What about capability negotiation? Server offers capabilities, client
> >> can accept or decline them.
> >>
> >> [...]
> >
> > I think the easiest way to have this would be to add a
> > monitor command to disable capabilities. Like a command to
> > disable async messages.
>
> Greeting capabilities (for lack of a better word) are for the protocol.
> Changing protocol capabilities while you use the protocol is awkward.
> Better do it in an initial handshake.
If we use this to supppress/enable messages, I think
it's clear we need to support changing them on the fly.
> Case in point: if you disable asynchronous messages with a command, you
> still have to be prepared to receive one between initial handshake and
> completion of the disable command. If I have to ignore them anyway, why
> bother with disabling them?
For debug messages, sending and discarding them might have
performance impact.
> The problem becomes more serious if we ever want to add a capability
> that isn't fully backward compatible. Lack of feature negotiation
> limits protocol evolvability.
Some kind of version is the usualy way to do this.
--
MST