qemu-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]