qemu-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]