[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command |
Date: |
Sat, 27 Jun 2009 12:58:33 -0300 |
On Fri, 26 Jun 2009 10:42:24 +0100
"Daniel P. Berrange" <address@hidden> wrote:
> On Fri, Jun 26, 2009 at 12:21:01PM +0300, Avi Kivity wrote:
> > On 06/25/2009 10:11 PM, Luiz Capitulino wrote:
> > >
> > > Yes, having a library was suggested by Amit some months ago. The
> > >problem is that it has various issues wrt maintainability.
> > >
> > > For example, libvirt is able to run two instances of different
> > >versions of qemu at the same time. How to handle this if you
> > >update libmonitor.so?
> > >
>
> The sane way is to *NOT* break ABI of libmonitor.so, and not change
> the wire protocol in a non backwards compatible way. This is entirely
> doable, it just the maintainer of libmonitor/qemu to decide that ABI
> stability is important. So if you find an existing API / command
> needs to gain an extra argument, you don't change the existing API,
> you add a new one. Or ideally design the API upfront so that it
> can be extended without breaking back compatability.
[ Looks like my (evil) twin brother has taken the keyboard while I
was away and has started saying libmonitor.so non-sense. ]
I think I have mixed up problems here, but anyway, working on a C library
seems a step back to me. I believe that defining the API for it will
generate more discussion than the protocol, will probably be harder
to write and to document too.
In a general way the protocol idea is very simple: we just have to
make monitor's output parsable. As Anthony has put it, the patchset
is not far from a mergeable state. I can't even image how long it would
take to have the C API in the same shape.
That said, I think the protocol discussion went way too far. Of
course that I want to do the right thing and we should always be
concerned with the future, but the priority here is not to design/choose
the next-ultra-super-hiper-mathematically-proven-and-loved protocol.
So, IMHO both solutions (QMP and JSON) solves the problem and I
would work on either one. I just would like that Anthony and Avi
get in agreement, because the project will fail if it becomes
one more difference between qemu and qemu-kvm.
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, (continued)
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Anthony Liguori, 2009/06/23
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Luiz Capitulino, 2009/06/23
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Anthony Liguori, 2009/06/23
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Dor Laor, 2009/06/25
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Luiz Capitulino, 2009/06/25
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Avi Kivity, 2009/06/26
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Daniel P. Berrange, 2009/06/26
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Avi Kivity, 2009/06/26
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command,
Luiz Capitulino <=
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Avi Kivity, 2009/06/28
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Blue Swirl, 2009/06/28
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Filip Navara, 2009/06/28
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Avi Kivity, 2009/06/28
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Blue Swirl, 2009/06/28
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Avi Kivity, 2009/06/28
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Jamie Lokier, 2009/06/28
- Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command, Anthony Liguori, 2009/06/25