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.
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.
Now, if everything is disabled by default and qemu might be running
already, do we really need to have a handshake?
I think it's valuable to have a discrete period of time when no commands
have been executed where features can be enabled. It simplifies some
nasty edge conditions regarding enabling features while there are
outstanding commands in flight.
Regards,
Anthony Liguori
