[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: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] [PATCH 0/8]: QMP feature negotiation support |
Date: |
Tue, 2 Feb 2010 10:12:15 -0200 |
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.
It's possible to do this with a command like feature, but it'll get
bloated over time.