From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ6eH-0003o7-KZ for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:06:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ6eC-0003iZ-CI for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:06:57 -0400 Received: from [199.232.76.173] (port=36720 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ6eC-0003i2-5K for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:06:52 -0400 Received: from mail-fx0-f209.google.com ([209.85.220.209]:41992) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ6eB-0001ge-KE for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:06:51 -0400 Received: by fxm5 with SMTP id 5so84239fxm.34 for ; Tue, 23 Jun 2009 07:06:50 -0700 (PDT) Message-ID: <4A40E175.3060200@codemonkey.ws> Date: Tue, 23 Jun 2009 09:06:45 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode References: <20090623013005.39e27923@doriath> <4A409A4D.8030605@siemens.com> <20090623100428.GD6881@redhat.com> <4A40AA3D.2050807@siemens.com> <4A40AB9D.6040204@redhat.com> In-Reply-To: <4A40AB9D.6040204@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: aliguori@us.ibm.com, ehabkost@redhat.com, Jan Kiszka , dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino Avi Kivity wrote: > On 06/23/2009 01:11 PM, Jan Kiszka wrote: >>> 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. >> > > It would be a nightmare, consider both libvirt and a user hotplugging > something into the same pci slot, or a user starting migration, or > quitting, or ... > > Having -monitor readonly makes sense. I don't like such a concept. If a user goes to the trouble to create a second monitor, then they need to know what they're doing. libvirt can simply not expose the option to the user. Clever users can change the emulator tag to point to a script that they can use to create a second monitor. Regards, Anthony Liguori