From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LN4Bq-0001Hg-4b for qemu-devel@nongnu.org; Wed, 14 Jan 2009 06:45:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LN4Bp-0001GF-2l for qemu-devel@nongnu.org; Wed, 14 Jan 2009 06:45:41 -0500 Received: from [199.232.76.173] (port=49939 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LN4Bo-0001Fq-SV for qemu-devel@nongnu.org; Wed, 14 Jan 2009 06:45:40 -0500 Received: from mx1.redhat.com ([66.187.233.31]:54028) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LN4Bo-0002UP-FZ for qemu-devel@nongnu.org; Wed, 14 Jan 2009 06:45:40 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n0EBjdeJ017747 for ; Wed, 14 Jan 2009 06:45:39 -0500 Date: Wed, 14 Jan 2009 11:45:38 +0000 From: "Daniel P. Berrange" Message-ID: <20090114114538.GH24995@redhat.com> References: <20090114111005.GB31839@amit-x200.pnq.redhat.com> <20090114112938.GA11242@amd.home.annexia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090114112938.GA11242@amd.home.annexia.org> Subject: [Qemu-devel] Re: Machine-readable or parseable qemu output Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: Amit Shah , chrisw@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, avi@redhat.com 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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|