From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ2rk-0000s3-J4 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:04:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ2rf-0000ra-Sh for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:04:35 -0400 Received: from [199.232.76.173] (port=51619 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ2rf-0000rX-Fu for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:04:31 -0400 Received: from mx1.redhat.com ([66.187.233.31]:45154) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ2re-0000KH-Vb for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:04:31 -0400 Date: Tue, 23 Jun 2009 11:04:28 +0100 From: "Daniel P. Berrange" Message-ID: <20090623100428.GD6881@redhat.com> References: <20090623013005.39e27923@doriath> <4A409A4D.8030605@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A409A4D.8030605@siemens.com> Subject: [Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: aliguori@us.ibm.com, ehabkost@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , avi@redhat.com On Tue, Jun 23, 2009 at 11:03:09AM +0200, Jan Kiszka wrote: > Luiz Capitulino wrote: > > This change adds a flag called 'control' to the already existing > > '-monitor' command-line option. This flag can be used to enable > > control mode. > > > > Its syntax is: > > > > qemu [...] -monitor control, > > > > Where is a chardev (excluding 'vc', for obvious reasons). > > > > For example: > > > > $ qemu [...] -monitor control,tcp:localhost:4444,server > > > > Will run QEMU in control mode, waiting for a client TCP connection > > on localhost port 4444. > > > > Signed-off-by: Luiz Capitulino > > At this chance, I would vote for "[PATCH 12/11] Allow multiple -monitor > instances". I think Anthony posted such a patch before. Now we should > really include this as your extension may block the stand-alone -monitor > switch for the control channel, preventing to additionally set up one > (or more) for debugging purposes. If we support multiple monitors, it might be desirable to allow the app owning the main 'control' monitor channel to be able to indicate that additional monitor channels are read-only. eg, so libvirt could allow the user to connect to the monitor to run 'info' commands for debug support without risk of having state changed behind its back Regards, 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 :|