From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ6XI-00076b-Bj for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:59:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ6XD-000745-9I for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:59:43 -0400 Received: from [199.232.76.173] (port=57989 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ6XD-00073y-44 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:59:39 -0400 Received: from mx2.redhat.com ([66.187.237.31]:40524) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ6XC-0008Vq-Gs for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:59:38 -0400 Date: Tue, 23 Jun 2009 10:59:30 -0300 From: Luiz Capitulino Message-ID: <20090623105930.7718400e@doriath> In-Reply-To: <4A409A4D.8030605@siemens.com> References: <20090623013005.39e27923@doriath> <4A409A4D.8030605@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode 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, avi@redhat.com On Tue, 23 Jun 2009 11:03:09 +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. Do you really think that this is needed for the first version? I would rather prefer to concentrate on protocol specification and command porting, which will require a lot of effort.