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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Tue, 02 Feb 2010 09:03:32 +0100
Markus Armbruster <armbru@redhat.com> wrote:

> Luiz Capitulino <lcapitulino@redhat.com> writes:
> 
> > On Mon, 01 Feb 2010 20:37:41 +0100
> > Markus Armbruster <armbru@redhat.com> wrote:
> >
> >> Luiz Capitulino <lcapitulino@redhat.com> writes:
> >> 
> >> > On Mon, 01 Feb 2010 18:08:27 +0100
> >> > Markus Armbruster <armbru@redhat.com> 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.

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