Anthony Liguori <anth...@codemonkey.ws> writes: > On 01/11/2010 06:04 PM, Luiz Capitulino wrote: [...] >>>> 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.
Agreed. >> 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. That's exactly why I lobbied for feature negotiation in the initial handshake, i.e. client connects, server sends greeting with features, client sends features it wants enabled, and only then we enter the normal command loop. Protocol that don't have that tend to get it retrofitted when they evolve. Let's do it now, before backward compatibility concerns force us to do it in an ugly way.
