From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nv47F-0004Nm-I0 for qemu-devel@nongnu.org; Fri, 26 Mar 2010 03:38:01 -0400 Received: from [140.186.70.92] (port=51962 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nv479-0004LC-SH for qemu-devel@nongnu.org; Fri, 26 Mar 2010 03:38:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nv476-0000BM-R1 for qemu-devel@nongnu.org; Fri, 26 Mar 2010 03:37:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21424) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nv476-0000B9-9G for qemu-devel@nongnu.org; Fri, 26 Mar 2010 03:37:52 -0400 From: Markus Armbruster Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt 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> <4BAB1E21.8080009@snarc.org> <4BAB5805.9080000@codemonkey.ws> <4BAB58F1.20401@redhat.com> <4BAB68A2.6020707@codemonkey.ws> <4BABA00B.6020701@codemonkey.ws> Date: Fri, 26 Mar 2010 08:37:33 +0100 In-Reply-To: <4BABA00B.6020701@codemonkey.ws> (Anthony Liguori's message of "Thu, 25 Mar 2010 12:40:27 -0500") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "libvir-list@redhat.com" , qemu-devel@nongnu.org, Luiz Capitulino , Paul Brook , Vincent Hanquez , Avi Kivity Anthony Liguori writes: > On 03/25/2010 11:50 AM, Markus Armbruster wrote: >> >>> The point is, C is a lowest common denominator and it's important to >>> support in a proper way. >>> >> No. The lowest truly common denominator is plain text. And we got that >> covered already. >> >> A developer encountered the problem of talking a simple text protocol. >> He thought "I know, I'll create a 1:1 C API for that". Now he got two >> problems. >> > > I've done a poor job communicating in this thread. > > The C API's primary purpose is *not* to providing 1:1 wrapping > functions for QMP functions. That's a minor, add on feature, that I > really would like, but it not at all useful for high level languages. > > The importances of libqemu is: > > 1) Providing a common QMP transport implementation that is extensible > by third parties > 2) Providing a set of common transports that support automatic > discovery of command line launched guests > 3) Providing a generic QMP dispatch function Adding to this C wrappers for QMP commands threatens to make QMP command arguments part of the library ABI. Compatible QMP evolution (like adding an optional argument) turns into a libqmp soname bump. Counter-productive. How do you plan to avoid that? > Yes, this means you can't just create a JSON-RPC object in Python and > talk QMP that way, but that's less desirable than you think it is. > > You could if you really wanted to, but you wouldn't get the benefits > of the common transports. > > IOW, imagine qemu-cmd. You want it to support: > > # qmp_new_by_name("Fedora") > qemu-cmd Fedora set_link on > > # libqemu-ssh.so - ssh_qmp_new() > qemu-cmd ssh://anthony@lab1.ibm/Fedora set_link on > > # qmp_new_by_fd() > qemu-cmd -c /path/to/domain/socket set_link on > > # libvirt-qemu.so - virDomainGetQMP() > qemu-cmd -b qemu+ssh://lab1.ibm/system Fedora set_link on > > This requires a high level transport. All I'd want from such a transport is a file descriptor. No need to drag in yet another JSON library via libqmp.