From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LN3vl-0007b4-Vu for qemu-devel@nongnu.org; Wed, 14 Jan 2009 06:29:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LN3vk-0007XD-4Y for qemu-devel@nongnu.org; Wed, 14 Jan 2009 06:29:04 -0500 Received: from [199.232.76.173] (port=53050 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LN3vj-0007Wu-Tf for qemu-devel@nongnu.org; Wed, 14 Jan 2009 06:29:03 -0500 Received: from mx2.redhat.com ([66.187.237.31]:59640) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LN3vj-0008Up-5h for qemu-devel@nongnu.org; Wed, 14 Jan 2009 06:29:03 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0EBSjuv015935 for ; Wed, 14 Jan 2009 06:28:45 -0500 Message-ID: <496DCC68.4000509@redhat.com> Date: Wed, 14 Jan 2009 13:28:40 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20090114111005.GB31839@amit-x200.pnq.redhat.com> In-Reply-To: <20090114111005.GB31839@amit-x200.pnq.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Machine-readable or parseable qemu output Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: chrisw@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, rjones@redhat.com 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) > - 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. > - The API could be something like: > - execute_qemu_command(qemu_instance, command, args...); > > It'd much prefer qemu_hotplug_nic(...); qemu_migrate(..., callback); > - 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. > - The string generated by qemu monitor output should never be exposed to > the consumer > Right. > - Some monitor commands will generate some string that might be of use > to the consumer. Such a string will be passed to the consumer via some > other api, like > - get_string_from_last_command(qemu_instance, some_context); > Output parameters will do fine. > - There might be output that's asynchronous to the command. Finding the > correlation between the command and the output should not be the > library's job; an async_socket can be created per qemu instance and > the consumer can select() on this socket to poll for data. Whenever > some information becomes available, we can push it out. If the qemu > output would contain more information for async output, this can be > passed on to the consumer. > You're moving the protocol handling out from the protocol parser... -- error compiling committee.c: too many arguments to function