Re: [Qemu-devel] [PATCH 0/8]: QMP feature negotiation support

[Markus Armbruster]

Luiz Capitulino <address@hidden> writes:

> On Tue, 02 Feb 2010 09:03:32 +0100
> Markus Armbruster <address@hidden> wrote:
>
>> 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?
>
>  Not the best example since we agreed async messages setup could be done
> in operational mode, but in case other features will require it:
>
> 1. The async message feature _and_ each async message were disabled by
>    default
> 2. You could enable async message feature with capability_enable
> 3. Then, each message should be enabled separately with async_message_enable
>
>  The use case here is: a feature requires to be configured before the
> protocol is operational.

Okay, let's pretend for the sake of the argument that async message
enable/disable is core protocol, and thus needs to be controlled via
capabilities.

An obvious way is to have one capability for every enable/disable
switch.  The server's capability offer lists them all, and the client's
capability selection includes the one it wants.

What if this leads to dozens of capabilities?  It's a machine protocol,
and a machine can cope with sixty capabilities just as fine as with six.
Six hundred would be kind of ugly, though.

If we absolutely insist on controlling async messages with a single
capability, things get slightly more complex.  The capability now sports
an object value, with a member for each enable/disable switch.  The
client's capability client selection supplies such an object value.

If we're worried about discoverability, we can make the server's
capability offer include a description of each capability's value.

And now let's quit pretending, and remind ourselves that capabilities
are for variations of the core protocol.  Do we really expect the core
protocol to become so baroque that we'll need a full-blown configuration
mode?

>  It's possible to do this with a command like feature, but it'll get
> bloated over time.

I doubt it.