From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ3wu-0000Gz-9u for qemu-devel@nongnu.org; Tue, 23 Jun 2009 07:14:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ3wk-0000Df-IM for qemu-devel@nongnu.org; Tue, 23 Jun 2009 07:13:55 -0400 Received: from [199.232.76.173] (port=51153 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ3wk-0000DB-6G for qemu-devel@nongnu.org; Tue, 23 Jun 2009 07:13:50 -0400 Received: from gecko.sbs.de ([194.138.37.40]:15666) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJ3wj-0007o6-KZ for qemu-devel@nongnu.org; Tue, 23 Jun 2009 07:13:50 -0400 Message-ID: <4A40B8EA.1030600@siemens.com> Date: Tue, 23 Jun 2009 13:13:46 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20090623013005.39e27923@doriath> <4A409A4D.8030605@siemens.com> <20090623100428.GD6881@redhat.com> <4A40AA3D.2050807@siemens.com> <20090623101939.GG6881@redhat.com> In-Reply-To: <20090623101939.GG6881@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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: "Daniel P. Berrange" Cc: aliguori@us.ibm.com, ehabkost@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , avi@redhat.com Daniel P. Berrange wrote: > On Tue, Jun 23, 2009 at 12:11:09PM +0200, Jan Kiszka wrote: >> Daniel P. Berrange wrote: >>> 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 >> Couldn't libvirt deal with update given we provide them as events? >> Otherwise, your suggestion makes sense, definitely as long as it would >> wreck libvirt's internal house keeping or for commands that are not >> synchronizable. > > If the mgmt app knows about & supports all features in the QEMU its > talking to, and we generate events for all possible changes, then it > could detect & cope with changes. In reality though I don't think > you can expect mgmt apps to have complete coverage of all features, > so it would be safer for them to be able to designate additional > monitor channels readonly. Also reading your valid concerns regarding event queue overflows, I think making it flexible /wrt asynchronous changes will actually make the whole think much more robust than simply trying to block every competing change. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux