|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] QMP forward compatibility support |
Date: | Mon, 11 Jan 2010 18:24:24 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0 |
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 usingWhy 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
[Prev in Thread] | Current Thread | [Next in Thread] |