Re: [Qemu-devel] QMP forward compatibility support

[Luiz Capitulino]

On Wed, 13 Jan 2010 17:53:38 +0100
Markus Armbruster <address@hidden> wrote:

> 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.

 Ok, will do.

> >> >>> 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?

 I think that playing with some protocol bits might be safe, like
enabling async messages.

 I'm not saying this is a good practice, but forbidding it seems a bit
extreme at first.