From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNafa-0001Fb-FW for qemu-devel@nongnu.org; Thu, 15 Jan 2009 17:26:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNafY-0001Er-Om for qemu-devel@nongnu.org; Thu, 15 Jan 2009 17:26:34 -0500 Received: from [199.232.76.173] (port=38596 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNafY-0001Ej-GW for qemu-devel@nongnu.org; Thu, 15 Jan 2009 17:26:32 -0500 Received: from qw-out-1920.google.com ([74.125.92.145]:17697) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNafY-00057v-3N for qemu-devel@nongnu.org; Thu, 15 Jan 2009 17:26:32 -0500 Received: by qw-out-1920.google.com with SMTP id 5so295819qwc.4 for ; Thu, 15 Jan 2009 14:26:30 -0800 (PST) Message-ID: <496FB809.9020201@codemonkey.ws> Date: Thu, 15 Jan 2009 16:26:17 -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> <496FAF16.6040205@redhat.com> In-Reply-To: <496FAF16.6040205@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: Avi Kivity Cc: chrisw@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, rjones@redhat.com, Amit Shah Avi Kivity wrote: > Daniel P. Berrange wrote: >>> 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. >> > > Perhaps libvirt can donate its parsing code for use as a fallback in > libqemumonitor.so. Or split it out into an another library. I really don't think it's a good idea to maintain it within QEMU because it's against an interface that was never supported in QEMU and doesn't exist in the existing QEMU code base. Regards, Anthony Liguori