From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nv97R-0006cl-1O for qemu-devel@nongnu.org; Fri, 26 Mar 2010 08:58:33 -0400 Received: from [140.186.70.92] (port=56059 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nv97P-0006QV-L0 for qemu-devel@nongnu.org; Fri, 26 Mar 2010 08:58:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nv926-0006Sp-M8 for qemu-devel@nongnu.org; Fri, 26 Mar 2010 08:53:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61060) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nv926-0006Sk-Bs for qemu-devel@nongnu.org; Fri, 26 Mar 2010 08:53:02 -0400 Date: Fri, 26 Mar 2010 09:52:38 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt Message-ID: <20100326095238.6814997a@redhat.com> In-Reply-To: <4BAB6B5E.5040101@codemonkey.ws> References: <4BA7C40C.2040505@codemonkey.ws> <20100323145105.GV16253@redhat.com> <4BA8D8A9.7090308@codemonkey.ws> <201003231557.19474.paul@codesourcery.com> <4BA8E6FC.9080207@codemonkey.ws> <4BA901B5.3020704@redhat.com> <4BA9A066.3070904@redhat.com> <20100324103643.GB624@redhat.com> <4BA9EC88.6000906@redhat.com> <20100324134250.38822113@redhat.com> <4BAA6CD9.6060001@redhat.com> <20100324171219.4365318b@redhat.com> <4BAA76EA.2060601@codemonkey.ws> <20100324182501.000b69a7@redhat.com> <4BAA86C2.4020701@codemonkey.ws> <20100325102309.5119918c@redhat.com> <4BAB6B5E.5040101@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org, Avi Kivity On Thu, 25 Mar 2010 08:55:42 -0500 Anthony Liguori wrote: > On 03/25/2010 08:23 AM, Luiz Capitulino wrote: > > On Wed, 24 Mar 2010 16:40:18 -0500 > > Anthony Liguori wrote: > > > > > >>>> We need to have a common management interface for third party tools. > >>>> > >>>> > >>> QMP? :-) > >>> > >> Only if QMP is compatible with libvirt. I don't want a user to have to > >> choose between QMP and libvirt. > >> > > Why not? If all they want is a simple qemu session, they can use > > QMP directly, on the other hand if what they want is more complex, > > what's the problem of using a management API like libivrt? > > > > My point is that libvirt should not be a separate management API but > effectively an add-on API that provides higher level features, better > integration with Linux host services, etc. Okay, I fully agree here. > >>> If so, what C clients you expected beyond libvirt? > >>> > >> Users want a C API. I don't agree that libvirt is the only C interface > >> consumer out there. > >> > > Actually, I do agree. Maybe, we don't have other C consumers because they > > weren't crazy enough to parse the crap of the user Monitor (or they do, > > but for simple things). > > > > One possible future client is perf, for example. > > > > Here is my solution (actually it's not mine, you have suggested > > it some time ago): let's provide a convenient way for C clients to > > use QMP. That is, let's have an overly simple library which takes > > QDitcs, sends them to qemu through QMP and returns others QDicts. > > > > Something like the _sketch_ below: > > > > // Open a connection > > int qmp_open(..., QDict **greeting); > > > > // Register a callback for async messages, BUT note that the async message > > // object is passed verbatim > > void qmp_async_mes_handler(..., void (*async_mes_handler)(QDict *mes)); > > > > // Send a QMP command > > int qmp_send(..., const char *command, QDict *params, QDict **res); > > > > Yes, this is the core API. It's missing a mechanism to create a > QMPContext. I'll also argue that we want a set of auto generated > wrappers like: Having the wrappers is one of the points we disagree, but as we have agreed on starting with the core only, I don't see why keep arguing here. If, in the near feature, the need of having wrappers become evident I'll be all for it (this statement is a bit dangerous though, as this need can be subjective). [...] > > but the two main ideas are: > > > > 1. We don't do management > > > > I really believe we need to stop thinking this way. I'm not saying that > qemu-devel is the place where we design virt-manager, but we ought to > consider the whole stack as part of "we". Depends, if you mean that we should be involved with libvirt development, than I completely agree. On the other hand, if you mean than qemu should provide its own management API, than I tend to disagree. And I think this is a very important point of the whole discussion, if you think this way I guess we should start a new thread to collect feedback, listing pros and cons. > >> I really think what we want is for a libvirt user to be able to call > >> libqemu functions directly. There shouldn't have to be libvirt specific > >> functions for every operation we expose. > >> > > Not sure if this is too crazy but, considering this user wants to > > use qemu features not implemented by libvirt yet, what about using both > > libqmp (above) and libvirt at the same time? > > > > Yes, that's *exactly* what I want. Except I want to call it libqemu > because qmp is an implementation detail. libqemu is fine.