From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNYsC-0005bg-On for qemu-devel@nongnu.org; Thu, 15 Jan 2009 15:31:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNYsB-0005Ym-4W for qemu-devel@nongnu.org; Thu, 15 Jan 2009 15:31:27 -0500 Received: from [199.232.76.173] (port=56561 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNYsA-0005Xh-7x for qemu-devel@nongnu.org; Thu, 15 Jan 2009 15:31:26 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:42588) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNYs9-0007If-Rn for qemu-devel@nongnu.org; Thu, 15 Jan 2009 15:31:26 -0500 Received: by qyk13 with SMTP id 13so1912236qyk.10 for ; Thu, 15 Jan 2009 12:31:25 -0800 (PST) Message-ID: <496F9D11.40304@codemonkey.ws> Date: Thu, 15 Jan 2009 14:31:13 -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> <20090114112938.GA11242@amd.home.annexia.org> <20090114114538.GH24995@redhat.com> In-Reply-To: <20090114114538.GH24995@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" , qemu-devel@nongnu.org Cc: Amit Shah , chrisw@redhat.com, dlaor@redhat.com, "Richard W.M. Jones" , avi@redhat.com Daniel P. Berrange wrote: > On Wed, Jan 14, 2009 at 11:29:38AM +0000, Richard W.M. Jones wrote: > >> On Wed, Jan 14, 2009 at 04:40:05PM +0530, Amit Shah wrote: >> >>> - Have a libqemumonitor.so that will abstract out output from qemu and >>> provide a machine-readble output for the consumer >>> >> Why do we need a C API at all? IMHO it'd be better just to make the >> existing qemu monitor output more machine-friendly, meaning consistent >> delimiters so that programs can reliably resynchronize with the >> output, and consistent guarantees on error messages. >> > > Well if we have async messages over a separate channel, we can already > reliably resynchronize with the output, because QEMU will eventually > produce its '(qemu) ' prompt on a new line. So if something goes wrong > you just need to skip until you find the prompt again. Changing QEMU > monitor prompt will just break all existing libvirt deployments, and > any other programs relying on currently prompt. > > IMHO, any libqemumonitor.so should be made to work with current monitor > format as its starting point, and then extend from there, not change > any existing characteristics. This provides forwards & backwards compat > for all apps, albeit at cost of slightly more complex internals for > the libqemumonitor.so - but this complexity will be centralized in one > place instead of all apps using QEMU, so this is still a net win. > The monitor today is *not* meant to be parsed. I know people do it, but it's not intended to. I don't want to introduce all the nutty complexity into QEMU to pretend like it's been a supported interface since 0.8.0. Let's make it a supported, stable interface and move forward. Regards, Anthony Liguori > Daniel >