[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QMP forward compatibility support
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] QMP forward compatibility support |
Date: |
Tue, 12 Jan 2010 10:11:02 -0200 |
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.
> >>> 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
- [Qemu-devel] QMP forward compatibility support, Luiz Capitulino, 2010/01/11
- Re: [Qemu-devel] QMP forward compatibility support, Anthony Liguori, 2010/01/11
- Re: [Qemu-devel] QMP forward compatibility support, Daniel P. Berrange, 2010/01/11
- Re: [Qemu-devel] QMP forward compatibility support, Luiz Capitulino, 2010/01/11
- Re: [Qemu-devel] QMP forward compatibility support,
Luiz Capitulino <=
- Re: [Qemu-devel] QMP forward compatibility support, Markus Armbruster, 2010/01/13
- Re: [Qemu-devel] QMP forward compatibility support, Luiz Capitulino, 2010/01/13
- Re: [Qemu-devel] QMP forward compatibility support, Markus Armbruster, 2010/01/13
- Re: [Qemu-devel] QMP forward compatibility support, Luiz Capitulino, 2010/01/13
- Re: [Qemu-devel] QMP forward compatibility support, Jamie Lokier, 2010/01/13