From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNZn8-00085o-NM for qemu-devel@nongnu.org; Thu, 15 Jan 2009 16:30:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNZn6-00083y-GR for qemu-devel@nongnu.org; Thu, 15 Jan 2009 16:30:18 -0500 Received: from [199.232.76.173] (port=41835 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNZn5-00083c-Uy for qemu-devel@nongnu.org; Thu, 15 Jan 2009 16:30:16 -0500 Received: from qw-out-1920.google.com ([74.125.92.149]:6361) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNZn5-0007aB-CG for qemu-devel@nongnu.org; Thu, 15 Jan 2009 16:30:15 -0500 Received: by qw-out-1920.google.com with SMTP id 5so290720qwc.4 for ; Thu, 15 Jan 2009 13:30:14 -0800 (PST) Message-ID: <496FAADA.8070401@codemonkey.ws> Date: Thu, 15 Jan 2009 15:30:02 -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> <20090114112317.GD24995@redhat.com> <496F9C19.8020502@codemonkey.ws> <20090115205842.GJ23380@redhat.com> In-Reply-To: <20090115205842.GJ23380@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" Cc: chrisw@redhat.com, dlaor@redhat.com, rjones@redhat.com, qemu-devel@nongnu.org, avi@redhat.com, Amit Shah Daniel P. Berrange wrote: > On Thu, Jan 15, 2009 at 02:27:05PM -0600, Anthony Liguori wrote: > >> Daniel P. Berrange wrote: >> >>> On Wed, Jan 14, 2009 at 04:40:05PM +0530, 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? >>>> >>>> >>> I'd like to add one more requirement >>> >>> - Works with existing QEMU monitor for releases >= 0.8.0 >>> >>> >> I think this is a bad requirement. >> >> >>> This is because libvirt currently supports all QEMU >= 0.8.0, >>> >> libvirt has no bearing on upstream QEMU support :-) >> >> >>> so if >>> we're to be able to make use of this library we can't restrict it >>> to just new releases. >>> >> But you can conditionally use the new library instead of your custom >> parsing code for newer QEMU versions. >> > > That is true, but if there are a number of apps around which want to > support multiple versions of QEMU, it is beneficial to centralize > this conditional logic in libqemumonitor.so instead, of making each > app implement the compat logic for the existing monitor format. I'm > not against adding a new machine friendly monitor format, I'd just > prefer it if one library API could provide impl for both old and new > format, obviously preferring to use the new format where available. > But then we have to design the API around what was parsable from the old monitor interface or provides complex probing interfaces to see what features are supported. This is a much more constrained problem for libvirt because it only accesses a subset of what the monitor does but when you do it at the QEMU level, there will be an expectation that we need to support everything that's done through the monitor. I'm concerned this will get very ugly very quickly. Regards, Anthony Liguori > Daniel >