From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J26Kt-0000mD-IX for qemu-devel@nongnu.org; Tue, 11 Dec 2007 09:43:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J26Kn-0000kM-If for qemu-devel@nongnu.org; Tue, 11 Dec 2007 09:43:51 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J26Kn-0000kG-6A for qemu-devel@nongnu.org; Tue, 11 Dec 2007 09:43:45 -0500 Received: from nz-out-0506.google.com ([64.233.162.230]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J26Kn-0004KW-2M for qemu-devel@nongnu.org; Tue, 11 Dec 2007 09:43:45 -0500 Received: by nz-out-0506.google.com with SMTP id f1so3552058nzc for ; Tue, 11 Dec 2007 06:43:42 -0800 (PST) Message-ID: <475EA21B.9060609@codemonkey.ws> Date: Tue, 11 Dec 2007 08:43:39 -0600 From: Anthony Liguori 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> In-Reply-To: <475E6F02.9000302@qumranet.com> Content-Type: text/plain; charset=ISO-8859-1; 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: qemu-devel@nongnu.org Avi Kivity wrote: > Fabrice Bellard wrote: >> Hi, >> >> At this point I am not interested in integrating it into QEMU as it >> is one more API level to maintain in addition to the command line >> monitor. However, I can change my mind if several projects insists to >> have a similar interface. >> > > 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. Why not just improve the monitor interface? Half the internet is based on human-readable text protocols. I don't think there would be a lot of objections to adding a status field with each monitor command. It could even be done in a way that was backwards compatible. For instance: (qemu) info kqemu kqemu support is not compiled in (qemu) verbosity status (qemu) info kqemu -38: kqemu support is not compiled in The other two things to add to the monitor are support for multiple simultaneous connections and some sort of select command. Regards, Anthony Liguori