From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LN92a-0003BB-EE for qemu-devel@nongnu.org; Wed, 14 Jan 2009 11:56:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LN92Z-0003AH-Mr for qemu-devel@nongnu.org; Wed, 14 Jan 2009 11:56:27 -0500 Received: from [199.232.76.173] (port=56673 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LN92Z-0003A9-GC for qemu-devel@nongnu.org; Wed, 14 Jan 2009 11:56:27 -0500 Received: from mail2.shareable.org ([80.68.89.115]:56633) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LN92Y-0004p6-UU for qemu-devel@nongnu.org; Wed, 14 Jan 2009 11:56:27 -0500 Date: Wed, 14 Jan 2009 16:56:22 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: Machine-readable or parseable qemu output Message-ID: <20090114165622.GD6431@shareable.org> 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> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Amit Shah , chrisw@redhat.com, dlaor@redhat.com, avi@redhat.com Although it's nice to have a monitor which is human-readable, many programs have a separate monitor _program_ which connects over a unix socket to the running app. For example, Bind has rndc, ntpd has ntpdc, apache has apachectl, and Samba has smbcontrol. This gives all the benefits of a machine-accessible monitor, including asynchronous events, waiting for long commands (like migrate) while still doing useful things (like change the CD while migrating? :-) It's much more scriptable to have a separate program, and you still have a nice text UI with line-editing, help, etc. Possibly a nicer UI, since it's not limited to telnet/serial. For QEMU, maybe it would work to define a machine-accessible socket protocol, and move the current QEMU monitor code to a separate app which connects over that protocol? If QEMU is invoked with arguments asking for the current monitor over e.g. a socket, telnet socket or serial port, it'd be easy for QEMU to fork/exec the monitor app. The same app would be invokable from scripts. -- Jamie