From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J27gm-0003qr-VV for qemu-devel@nongnu.org; Tue, 11 Dec 2007 11:10:33 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J27gm-0003qf-DH for qemu-devel@nongnu.org; Tue, 11 Dec 2007 11:10:32 -0500 Received: from mx1.polytechnique.org ([129.104.30.34]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J27gl-0004WF-Py for qemu-devel@nongnu.org; Tue, 11 Dec 2007 11:10:32 -0500 Message-ID: <475EB671.7070803@bellard.org> Date: Tue, 11 Dec 2007 17:10:25 +0100 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API References: <20071211154441.GH17368@redhat.com> In-Reply-To: <20071211154441.GH17368@redhat.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: "Daniel P. Berrange" , qemu-devel@nongnu.org Daniel P. Berrange wrote: > On Tue, Dec 11, 2007 at 09:16:43AM +0200, Yuval Kashtan wrote: >> - This is very useful when you want to manage and control QEMU, for instance >> developing a GUI to attach and detach usb devices or controlling more than >> one instance of QEMU from a single management point, receiving parameters >> externally and more. > > This capability is already possible using the monitor API. I've implemented > it in libvirt, and in virt-manager and can easily hotplug/remove USB devices. > So DBus is not required to do this and does not really make it any easier > to use. DBus is very verbose to use from languages like C, so switching from > the monitor to DBus API would not really help simplify my existing code. On > the other hand, having a library providing a simple client side C API to > send & receive monitor commands, would be beneficial For the short term I think it is better as you said to rely on libvirt which already has some support for QEMU. As it was suggested, improving the monitor seems the easiest, maybe with an additionnal mode to provide a standardized way to get a return value for each command. Providing an example client code to directly use the monitor seems a good idea too. Regarding the configuration, I can assure there will be soon a QEMU configuration file. The question is whether it will be included before the next release is out ! Regards, Fabrice.