Re: [Qemu-devel] QMP forward compatibility support

[Markus Armbruster]

Luiz Capitulino <address@hidden> writes:

> On Mon, 11 Jan 2010 18:24:24 -0600
> Anthony Liguori <address@hidden> wrote:
>
>> On 01/11/2010 06:04 PM, Luiz Capitulino wrote:
>> >
>> >   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.
>> >    
>> 
>> Right, but then it's not a capability, it's a core feature.  I just 
>> think it would be odd to advertise something as a capability and have it 
>> not behave like other ones.
>
>  Ok, so options are: call it a core feature and don't change anything
> or call it a capability and make it behave like any other capability.
>
>  What's the better? Should we vote? :) Daniel seems to prefer the
> later.

If it's optional, leave it off by default because the consensus seems to
be to leave all optional features off by default.

It should be optional if we want to support clients that don't want it.
I don't think coping with it would be a terrible burden on clients, but
neither is having to ask for it.  Personally, I'd make it optional.

>> >>> 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.
>> >    
>> 
>> I think forcing the negotiation before executing any commands is a good 
>> idea.  But I don't think requiring the guest not to be running is 
>> necessary or even useful.
>> 
>> You don't want to have to support disabling and enabling features in the 
>> middle of a protocol session because then you have to deal with weird 
>> semantics.
>
>  That's true, but I thought that doing that with pause mode was
> going to be better because it didn't require any change on QMP side.
>
>  If this is a bad approach, then I was wrong.
>
>  Now, making this part of the initial handshake brings some more
> design decisions and by making async messages a capability helps
> to test them.
>
>  I'm thinking in something like this:
>
> 1. Connection is made, the greeting message is sent and QMP is
> in 'handshake mode'
>
> 2. In this mode only commands to enable/disable protocol
> capabilities are allowed
>
> 3. When the client is done with the setup, it issues the
> command 'enable-qmp', which puts the protocol into 'running mode',
> where any command is accepted

Really "any command"?  What about commands to enable/disable protocol
capabilities?