From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNYq4-0002oS-1z for qemu-devel@nongnu.org; Thu, 15 Jan 2009 15:29:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNYq2-0002mr-5A for qemu-devel@nongnu.org; Thu, 15 Jan 2009 15:29:15 -0500 Received: from [199.232.76.173] (port=56486 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNYq1-0002mO-JE for qemu-devel@nongnu.org; Thu, 15 Jan 2009 15:29:13 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:64535) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNYq0-00071H-8S for qemu-devel@nongnu.org; Thu, 15 Jan 2009 15:29:12 -0500 Received: by qyk13 with SMTP id 13so1910715qyk.10 for ; Thu, 15 Jan 2009 12:29:09 -0800 (PST) Message-ID: <496F9C88.2050109@codemonkey.ws> Date: Thu, 15 Jan 2009 14:28:56 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Machine-readable or parseable qemu output References: <20090114111005.GB31839@amit-x200.pnq.redhat.com> <496DCC68.4000509@redhat.com> In-Reply-To: <496DCC68.4000509@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: qemu-devel@nongnu.org Cc: Amit Shah , chrisw@redhat.com, dlaor@redhat.com, rjones@redhat.com Avi Kivity wrote: > Amit Shah wrote: >> Hello, >> >> Continuing from the thread at [1], building on Daniel's suggestions, I >> have jot down a few points as to how a libqemumonitor API could be >> developed. >> >> To recap, there has to be an interface to the qemu monitor in >> a way that wouldn't break even if the monitor output changes. This API >> will remain the same, so that consumers (libvirt, etc) can safely >> integrate with the monitor. >> >> Please see Dan's email at [1] to get the background details. >> >> [1] http://www.mail-archive.com/qemu-devel@nongnu.org/msg14615.html >> >> Here are some initial thoughts. Comments? >> >> - Have a libqemumonitor.so that will abstract out output from qemu and >> provide a machine-readble output for the consumer >> >> - Registering with a particular qemu instance: >> - qemu_instance = attach_to_qemu("/path/to/socket"); >> > > qemu chrdev ("tcp:host:port", etc) Yes. The QEMU chrdev code can be reused too. >> - The strings in qemu monitor can change but the libqemumonitor has to >> change accordingly as well to keep the API consistent. >> > > No, they can't. The monitor client and qemu will be upgraded > independently. +1 >> - The API could be something like: >> - execute_qemu_command(qemu_instance, command, args...); >> >> > > It'd much prefer > > qemu_hotplug_nic(...); > qemu_migrate(..., callback); I concur. >> - In addition to the return value seen of the loglevel type from the >> monitor, there can be additional return values that can be provided >> based on the command executed. This can be queried by: >> - get_info_on_prev_command(qemu_instance, &ret); >> - This can give command-specific return values, like success, >> invalid parameter, etc. >> > > No, the command handler should parse the output expected from > executing the command. If the command is asynchronous, the command > handler should provide a callback. Agreed. Regards, Anthony Liguori