[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/8]: QMP feature negotiation support
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH 0/8]: QMP feature negotiation support |
Date: |
Tue, 02 Feb 2010 09:03:32 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Luiz Capitulino <address@hidden> writes:
> On Mon, 01 Feb 2010 20:37:41 +0100
> Markus Armbruster <address@hidden> wrote:
>
>> Luiz Capitulino <address@hidden> writes:
>>
>> > On Mon, 01 Feb 2010 18:08:27 +0100
>> > Markus Armbruster <address@hidden> wrote:
[...]
>> >> I don't doubt your design does the job. I just think it's overly
>> >> general. I had something far more stupid in mind:
>> >>
>> >> client connects
>> >> server -> client: version & capability offer (one message)
>> >> again:
>> >> client -> server: capability selection (one message)
>> >> server -> client: either okay or error (one message)
>> >> if error goto again
>> >> connection is now ready for commands
>> >>
>> >> No modes. The distinct lack of generality is a design feature.
>> >
>> > I like the simplicity and if we were allowed to change later I'd
>> > do it.
>> >
>> > The question is if we will ever want features to be _configured_
>> > before the protocol is operational. In this case we'd need to
>> > pass feature arguments through the capability selection command,
>> > which will get ugly and hard to use/understand.
>> >
>> > Mode oriented support doesn't have this limitation. Maybe we
>> > won't never really use it, but it's safer.
>>
>> Capability selection could be done as an object where the name/value
>> pairs are capability/argument. If you need multiple arguments for a
>> capability, make the capability's value an object.
>
> That's exactly what seems complicated to me, because besides performing
> two functions (enable/configure) some feature setup could require
> more commands to be done in a clear way.
What do you mean by "feature setup"? And how does it go beyond setting
a bunch of parameters?
> The async messages setup in the previous series was an example of this.
I don't remember the details. Could you summarize?
> As said we might never use this, but I wouldn't like to regret later.
A somewhat plausible example for how it could be needed would help.