[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED er
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message |
Date: |
Fri, 27 Aug 2010 16:24:13 -0300 |
On Fri, 27 Aug 2010 14:02:45 -0500
Anthony Liguori <address@hidden> wrote:
> On 08/27/2010 11:08 AM, Luiz Capitulino wrote:
> >> It's trying to plug a sieve with a band-aid. It's certainly an
> >> "improvement" but it's of question utility looking at the bigger picture.
> >>
> > Are you talking about the testing namespace idea? It doesn't have anything
> > to do with balloon or how our interfaces are built. It would be just a way
> > to play with commands that has been converted to QMP but are not available
> > because they're not stable yet (eg. Jan's device_show).
> >
>
> My point is that we shouldn't build any QMP APIs and we definitely
> shouldn't try to QMP-ize monitor commands.
>
> Instead, we should design logical C APIs that we could consume within
> QEMU that we think we can support long term and then expose those over QMP.
Comments on the Python comment below.
> Having a sandbox doesn't really solve the fundamental problem of making
> sure the interface is consumable.
It doesn't and it shouldn't. It's just a way to test commands that might
not be stable yet. A very minor feature, anyway.
> >> Balloon is a perfect example of where what we really need to do is build
> >> interface interfaces that make sense, and then expose them in QMP.
> >>
> > Main question is: can we drop the stats the way they are today to do the
> > Right Thing for 0.14 or not?
> >
>
> I don't see how 0.13.0 is going to get releases with anything but the
> current behavior. It's unfortunate but we're too delayed and can't
> afford a change like this this late in the game.
>
> In terms of the stable branch, the least disruptive thing would be a
> timeout.
Okay.
> > I think we have agreed on the internal interfaces approach. My only
> > concern is whether this will conflict when extending the wire protocol
> > (eg. adding new arguments to existing commands). Not a problem if the
> > C API is not stable, of course.
> >
>
> We don't do that. It's a recipe for disaster. QEMU isn't written in
> Python and if we try to module our interfaces are if we were a Python
> library, we're destined to fail.
You mean we don't do simple protocol extensions?
So, if we need an new argument to an existing command, we add a new
command instead? Just because QEMU is not written in Python?
> >> What's a reasonable C-level API to query statistics that potentially may
> >> never return? Building in a timeout is something of a crappy API
> >> because it puts policy deep in the API that is trivial to implement
> >> elsewhere. What you'd probably do is something like:
> >>
> >> BalloonStatsRequest *query_guest_balloon_stats(CompletionCallback *cb,
> >> void *opaque);
> >> int cancel_guest_balloon_stats(BalloonStatsRequest *req);
> >>
> > Shouldn't the API provide a general cancel method? All functions that
> > talk to the guest will need one.
> >
>
> See next proposal. There's no cancel but I'd argue it's not needed.
> You don't care if the request succeeds or fails so there's no point in
> cancelling it. Cancellation only works best when a request has a
> discrete life cycle but in the case of requesting a guest to update
> stats, there is not really a well define dstart and end.
>
> Regards,
>
> Anthony Liguori
>
> >> void release_guest_balloon_stats(BalloonStatsRequest *req);
> >>
> >> Regards,
> >>
> >> Anthony Liguori
> >>
> >>
> >>>>
> >>>>
> >>>>> Beyond fixing that regression, I agree that this command is terminally
> >>>>> flawed& we need to deprecate it& provide better specified new
> >>>>> replacement(s). This seems like 0.14 work to me though.
> >>>>>
> >>>>>
> >>>> Yup.
> >>>>
> >>>>
> >>>>
> >>>>> Regards,
> >>>>> Daniel
> >>>>>
> >>>>> [1] I know that they could already suffer if there was a bug in qemu
> >>>>> that prevented it responding, even if the guest was not being
> >>>>> malicious/crashed.
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
>
- [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, (continued)
- [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Daniel P. Berrange, 2010/08/27
- [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Anthony Liguori, 2010/08/27
- [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Daniel P. Berrange, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Markus Armbruster, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Luiz Capitulino, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Anthony Liguori, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Daniel P. Berrange, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Anthony Liguori, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Luiz Capitulino, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Anthony Liguori, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message,
Luiz Capitulino <=
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Anthony Liguori, 2010/08/27
- Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message, Luiz Capitulino, 2010/08/27
- Should QMP be RPC to internal C interfaces? (was: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message), Markus Armbruster, 2010/08/30
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Anthony Liguori, 2010/08/30
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Anthony Liguori, 2010/08/30
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Luiz Capitulino, 2010/08/30
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Anthony Liguori, 2010/08/30
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Markus Armbruster, 2010/08/31
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Luiz Capitulino, 2010/08/31
- [Qemu-devel] Re: Should QMP be RPC to internal C interfaces?, Anthony Liguori, 2010/08/31