[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [RFC] qapi: events in QMP
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] Re: [RFC] qapi: events in QMP |
Date: |
Tue, 15 Feb 2011 11:35:43 -0200 |
On Mon, 14 Feb 2011 14:15:27 -0600
Anthony Liguori <address@hidden> wrote:
> On 02/14/2011 01:58 PM, Luiz Capitulino wrote:
> > No, of course not, our plan has always been to do this via an schema,
> > the only reason we don't do this today is lack of time/help.
> >
> >
>
> Understood--I'm here to help now :-)
>
> >> We need to expose the schema, I'm not saying we shouldn't. But we don't
> >> today.
> >>
> >> You're arguing that we should extend commands by adding new parameters.
> >>
> > Commands and events, you haven't commented on events yet and that seems
> > a bit worse than commands.
> >
>
> Events are just commands that never return a value and are posted.
>
> IOW:
>
> client -> server message == command
> server -> client message == event
>
> However, we limit events to have no return value and semantically, when
> an event is invoked, the message is only posted (we're not guaranteed
> that the client has seen it).
>
> The reason for the lack of symmetry is to simplify the programming
> model. If we had to wait for an event to be ack'd and receive a return
> value, it would involve a lot of ugly callback registrations.
>
> But beyond those few limitations, events and commands should be treated
> exactly the same IMHO.
>
> > I disagree. Let's say we have added three new arguments to the command foo,
> > and now we have foo1, foo2 and foo3. I'm a quite old distro and only
> > have foo, which command should I backport? All of them? Only the latest?
> >
> > I can't see how easier this is. Backporting APIs will almost always suck.
> >
>
> 1) if we have to add three arguments to a command, we've failed in our
> API design after an initial release
Maybe. Still, having to add a new command because we wanted to make a simple
extension seems a bit overkill to me. I'm not sure how common this is going
to be, however when we discussed QMP originally there were a lot on emphasis
on this kind of feature.
What makes it pretty hard to work on this project is that we are always
changing our mind in a number of details.
> 2) it depends on what level of functionality the distro needs. The more
> complicated we make the API, the harder it will be to write clients
> against it. If we have four ways to do the same thing (even if that's
> via one command or four separate ones), writing a client is going to
> suck no matter what.
Yes, but I still do not see how easier it's going to be for a client
writer if s/he has to choose among four commands that do the same thing.
Please, note that I do see the internal benefits, as always, the disagreement
is about the wire protocol.
> > For C, yes. But one of the main goals of a high level protocol is to be
> > language independent, isn't it?
> >
>
> Yes, which means first-class support for a variety of languages with C
> being a very important one.
>
> >>> Look, although I did _not_ check any code yet, your description of the
> >>> QAPI
> >>> looks really exciting. I'm not against it, what bothers me though is this
> >>> number of small limitations we're imposing to the wire protocol.
> >>>
> >>> Why don't we make libqmp internal only? This way we're free to change it
> >>> whatever we want.
> >>>
> >>>
> >> libqmp is a test of how easy it is to use QMP from an external
> >> application. If we can't keep libqmp stable, then that means tools like
> >> libvirt will always have a hard time using QMP.
> >>
> >> Proper C support is important. We cannot make it impossible to write a
> >> useful C client API.
> >>
> > I wouldn't say it's impossible, but anyway, the important point here is
> > that we disagree about the side effects QAPI is going to introduce in QMP,
> > I don't know how to solve this, maybe we can discuss this upstream, but I'm
> > not sure the situation will change much.
> >
> > Should we vote? :)
> >
>
> Let's wait until I actually post patches... My purpose of this thread
> was to get some feedback on using signal/slots as an abstraction in QEMU.
Ok.
>
> The QMP conversion is almost done, I'll be able to post patches very soon.
>
> Regards,
>
> Anthony Liguori
>
- [Qemu-devel] Re: [RFC] qapi: events in QMP, (continued)
- [Qemu-devel] Re: [RFC] qapi: events in QMP, Kevin Wolf, 2011/02/14
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Anthony Liguori, 2011/02/14
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Kevin Wolf, 2011/02/14
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Luiz Capitulino, 2011/02/14
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Anthony Liguori, 2011/02/14
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Luiz Capitulino, 2011/02/14
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Anthony Liguori, 2011/02/14
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Luiz Capitulino, 2011/02/14
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Luiz Capitulino, 2011/02/14
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Anthony Liguori, 2011/02/14
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP,
Luiz Capitulino <=
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Markus Armbruster, 2011/02/15
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Kevin Wolf, 2011/02/15
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Luiz Capitulino, 2011/02/15
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Anthony Liguori, 2011/02/15
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Kevin Wolf, 2011/02/16
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Anthony Liguori, 2011/02/16
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Kevin Wolf, 2011/02/16
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Anthony Liguori, 2011/02/16
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Anthony Liguori, 2011/02/16
- Re: [Qemu-devel] Re: [RFC] qapi: events in QMP, Anthony Liguori, 2011/02/14