On Mon, 11 Jan 2010 18:24:24 -0600 Anthony Liguori <anth...@codemonkey.ws> 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. > >>> 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
