Re: [Qemu-devel] QMP forward compatibility support

[Luiz Capitulino <lcapitulino@redhat.com>]

On Mon, 11 Jan 2010 12:57:15 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 01/11/2010 12:34 PM, Luiz Capitulino wrote:
> >   Hi.
> >
> >   We (Markus and I) are working on getting QMP forward compatibility support,
> > supported. :)
> >
> >   We have a plan for it and I'd like to ask the CC'ed people to review it.
> >
> >   Needless to say, but the objective here is to add new commands, arguments,
> > async messages and protocol features w/o breaking existing clients.
> >
> > General Plan
> > ------------
> >
> > 1. QMP should describe itself, ie. it should dump all accepted commands,
> > their replies and arguments, async messages and protocol features. All in
> > JSON format
> >
> > 2. Protocol features are advertised by the (already existent) capabilities
> > array, but are _disabled_ by default. The exception is async messages,
> > which are _enabled_ by default
> >    
> 
> Any reason to have an exception like this?

 As async messages were one of the reasons for having QMP, I thought
that there was a consensus that making it part of the "original"
protocol was ok, meaning that they would be always available.

 That's the only reason.

> > 3. We should add command(s) to enable/disable protocol features
> >
> > 4. Proper feature negotiation is done in pause mode. That's, clients
> > interested in enabling new protocol features should start QEMU in
> > pause mode and enable the features they are interested in using
> >    
> 
> Why does this matter?
> 
> We should be careful to support connecting to a VM long after it's been 
> started so any requirement like this is likely to cause trouble.

 If I understood Markus's concerns correctly, he thinks that feature
negotiation should happen before the protocol is "running", ie. make
it part of the initial handshake.

 Now, if everything is disabled by default and qemu might be running
already, do we really need to have a handshake?