From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nur2x-0006YP-CW for qemu-devel@nongnu.org; Thu, 25 Mar 2010 13:40:43 -0400 Received: from [140.186.70.92] (port=49342 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nur2v-0006V2-3A for qemu-devel@nongnu.org; Thu, 25 Mar 2010 13:40:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nur2o-0004Da-S3 for qemu-devel@nongnu.org; Thu, 25 Mar 2010 13:40:39 -0400 Received: from mail-fx0-f221.google.com ([209.85.220.221]:39196) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nur2o-0004DI-Lu for qemu-devel@nongnu.org; Thu, 25 Mar 2010 13:40:34 -0400 Received: by fxm21 with SMTP id 21so6290989fxm.2 for ; Thu, 25 Mar 2010 10:40:33 -0700 (PDT) Message-ID: <4BABA00B.6020701@codemonkey.ws> Date: Thu, 25 Mar 2010 12:40:27 -0500 From: Anthony Liguori MIME-Version: 1.0 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: "libvir-list@redhat.com" , qemu-devel@nongnu.org, Luiz Capitulino , Paul Brook , Vincent Hanquez , Avi Kivity 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 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. Regards, Anthony Liguori