From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J27Tp-0003EP-I7 for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:57:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J27Tk-00032W-EF for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:57:09 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J27Tk-00032L-9s for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:57:04 -0500 Received: from il.qumranet.com ([82.166.9.18]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J27Tj-0002Fh-Qa for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:57:04 -0500 Message-ID: <475EB34D.4080303@qumranet.com> Date: Tue, 11 Dec 2007 17:57:01 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API References: <475E5403.2000705@bellard.org> <475E6F02.9000302@qumranet.com> <20071211145658.GB17368@redhat.com> In-Reply-To: <20071211145658.GB17368@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org Daniel P. Berrange wrote: >> >> I think that many projects now want to control qemu programatically. >> The monitor is not a good interface since it is text-based, hard to >> parse, and liable to change without notice when new features are added. >> However, I agree that having many similar constructs is not a good >> thing, and that we should retain the monitor for non-programmatic control. >> >> What do you say to implementing the qemu interface as a plugin API, and >> implementing the monitor on top of this API? e.g.: >> >> qemu loads /usr/local/lib/qemu/libmonitor.so, which uses the API to >> export the good old qemu monitor interface. If it finds >> /usr/local/lib/qemu/libdbus.so, it loads an additional dbus interface. >> If libvirt wants to drop a libvirtapi.so into that directory, it can >> control qemu through that. >> > > To be honest this is overkill. IMHO, there should simply be a client side > 'libqemumonitor.so' which provides a formal C API for applications to use. > libqemumonitor.so is an excellent idea. perhaps the libvirt code can be used as a base? We should also provide bindings to the saner languages that management apps are typically written in. -- error compiling committee.c: too many arguments to function