From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J218O-0001hK-9H for qemu-devel@nongnu.org; Tue, 11 Dec 2007 04:10:36 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J218N-0001gy-HS for qemu-devel@nongnu.org; Tue, 11 Dec 2007 04:10:35 -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 1J218N-00071B-4Y for qemu-devel@nongnu.org; Tue, 11 Dec 2007 04:10:35 -0500 Received: from fbe1.dev.netgem.com (gw.netgem.com [195.68.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTP id 4F1B53318C for ; Tue, 11 Dec 2007 10:10:28 +0100 (CET) Message-ID: <475E5403.2000705@bellard.org> Date: Tue, 11 Dec 2007 10:10:27 +0100 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API References: In-Reply-To: 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 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. Regards, Fabrice. Yuval Kashtan wrote: > Some answers: > - If there is interest I can re-create the patch so it will work against > the current head. I thought to receive some comments about it first.. > - thanks for the styling and configuration remarks, I will certainly fix > these. But before I invest more time in it, I would like to hear what > ppl think in general of management API? How do you like DBus as the > infrastructure for that? and what do you think of the proposed > implementation? > - Currently only commands are implemented (with very few getters), but > of course this can be further extended to include values reading and > statistics. > - 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. > > > On Dec 10, 2007 10:51 PM, Blue Swirl > wrote: > > On 12/10/07, Yuval Kashtan < yuvalkashtan@gmail.com > > wrote: > > Hello All, > > Attached is a proposed patch which adds DBus support to QEMU. > DBus is a > > standard message bus for linux > > ( http://www.freedesktop.org/wiki/Software/dbus ) > > The idea behind this is to allow for external programs such as > controlling > > GUI or HyperVisors to communicate and control QEMU, in a standard > manner. > > Although it is possible to connect to the monitor, an API is more > standard, > > theres no need to parse texts and error messages, no > internationalization > > problems and in general is a much better idea. > > > > Implementation: > > This is done by creating a DBus server from QEMU which raise > signals and act > > upon methods. > > Methods mainly implement same logic as the current command line > options and > > monitor does. > > > > How to use: > > To enable DBus support you'll have to add --enable-dbus when you > execure > > configure script. > > Then when you execute QEMU, you'll have to add -dbus-service > > > where service_name follows the DBus naming convention ( > xxx.xxx.xxx....) > > To support QEMU configuration through DBus, you'll also have to add > > -dbus_configuration which will cause QEMU to wait until > ConfigDone is called > > through the DBus interface. this allows external programs time to > call DBus > > methods starting with Config_ which changes configuration (just > as the CLI > > does) thus enabling invocation of QEMU without parameters (beside > the DBus > > ones). > > With that, we have implemented a nice python script that reads VM's > > configuration from INI file. > > > > To compile this you will also have to compile the attached > freedesktop.org > > dsrv library (it is also attach for those who can't handle GIT) from: > > git://people.freedesktop.org/~shaharf/dsrv > > > > Features: > > Currently support was added to all important CLI configuration > and some > > online monitor functions (such as connecting and disconnecting > usb devices). > > configuration methods begins with Config_ prefix and monitor ones > with > > Monitor_. > > For a complete list you can just execute qemu and connect with > dbus-viewer > > to see what is supported. > > > > > > All the dbus handling routines can be found in dbus-monitor.c. > > I have two different implementations of this: > > 1) A single threaded version. which comply to the qemu standard > of not > > opening additional threads. > > 2) A multi threaded version which open an additional, single, > thread which > > handles all the DBus load. I actually believe this version is > better as it > > allows QEMU to continue execution of guest operations even when > there are > > DBus methods/signals to handle, whereas in the first option, DBus is > > integrated into QEMU mainloop. Also this makes it possible to > monitor even > > during long operations (like monitoring the progress of savevm) > > > > > > Please comment both on the idea of management API and the proposed > > implementation. > > > > > > Attached are: > > RFC-QEMU-Dbus.patch - patch file including all necessary changes > to qemu. > > was made against QEMU HEAD as of 23/9 morning. > > RFC-QEMU-Dbus-Interface.xml - the xml description of the DBus > interface that > > I suggest. > > dsrv.tar.gz.txt - the dbus server library. > > I have no idea if this is useful. I would have tried the patch, but it > does not apply to current CVS. Other comments: > > When configure is invoked with --enable-dbus, it should check for DBUS > libraries and abort if not found. > > The coding style in monitor-dbus.c is different from what is commonly > used in Qemu. Some long lines could be shortened. > > Enabling of DEBUG_ACPI and other ACPI changes are probably not > directly needed so they should be in separate patches. > > Only commands are included, how about reading values and statistics? > > > > > > -- > Sincerly, > Yuval Kashtan