From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nv9yz-0008Lb-D8 for qemu-devel@nongnu.org; Fri, 26 Mar 2010 09:53:53 -0400 Received: from [140.186.70.92] (port=59509 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nv9yw-0008L3-ST for qemu-devel@nongnu.org; Fri, 26 Mar 2010 09:53:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nv9yv-0004qv-Gh for qemu-devel@nongnu.org; Fri, 26 Mar 2010 09:53:50 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:54987) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nv9yv-0004qn-7H for qemu-devel@nongnu.org; Fri, 26 Mar 2010 09:53:49 -0400 Received: by pwi9 with SMTP id 9so5926124pwi.4 for ; Fri, 26 Mar 2010 06:53:47 -0700 (PDT) Message-ID: <4BACBC68.5050401@codemonkey.ws> Date: Fri, 26 Mar 2010 08:53:44 -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> <4BABA00B.6020701@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/26/2010 02:37 AM, Markus Armbruster wrote: > 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? > I had thought about this. I think there's a couple ways to handle it. You could ignore it and just not change existing symbols. You could also introduce new functions any time an optional argument is added. Another option is to add a struct as a final argument whenever such a change happens that's padded. Then new optional arguments can be added to the struct. >> 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. > Then you don't standardize creation which is probably where most of the complexity occurs. Regards, Anthony Liguori