From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ4WK-0004cX-He for qemu-devel@nongnu.org; Tue, 23 Jun 2009 07:50:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ4WB-0004ZP-IF for qemu-devel@nongnu.org; Tue, 23 Jun 2009 07:50:32 -0400 Received: from [199.232.76.173] (port=34329 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ4WA-0004Z8-F7 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 07:50:26 -0400 Received: from mx2.redhat.com ([66.187.237.31]:36066) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ4W9-00012C-VB for qemu-devel@nongnu.org; Tue, 23 Jun 2009 07:50:26 -0400 Message-ID: <4A40C1B6.8080103@redhat.com> Date: Tue, 23 Jun 2009 14:51:18 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20090623013005.39e27923@doriath> <4A409A4D.8030605@siemens.com> <20090623100428.GD6881@redhat.com> <4A40AA3D.2050807@siemens.com> <4A40AB9D.6040204@redhat.com> <4A40B467.7000604@siemens.com> <4A40BC66.8040206@redhat.com> <4A40C01C.2070004@siemens.com> In-Reply-To: <4A40C01C.2070004@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, Luiz Capitulino On 06/23/2009 02:44 PM, Jan Kiszka wrote: >> I'm not saying it's impossible, just that we don't want to do it. >> > > I agree it's not something that is mandatory for the first versions, but > disagree that we should not strive for achieving this level of support > mid- to long-term. No design decision made today should prevent it, but > rather keep that door open. Also for robustness reasons (if you loose > contact to your qemu backend and need to resync the management frontend). > No objections here. Certainly reconnect is important. >> If libvirt "doesn't bother" about something useful, that's a libvirt >> bug. It's wierd to have something controlled by two parallel management >> channels. >> > > I think the libvirt policy is that things which are not generic enough > to be supported by>1 hypervisor are left alone. > That's a bit offtopic here, but it appears to me this dooms libvirt to be useless in all but the most basic use cases. Hypervisor writers try to new features to differentiate their products, and forcing users off libvirt in order to use them seems to be counterproductive. >>> See, I don't want to kill my management app just because I attached to a >>> guest via gdb and start injecting reconfiguration events for testing >>> purposes (e.g. attach/detach a USB device for which I develop a driver). >>> >>> >> You're talking about a usb developer, not a qemu developer, working in >> some virtual lab environment? In that case, libvirt and the management >> app should certainly support usb. A random usb developer shouldn't need >> to ever talk to the qemu monitor. >> > > I'm talking about, just as one example, sitting in front of my gdb > [frontend], doing guest kernel [driver] debugging and issuing "monitor > whatever" commands from one place, ie. not having to switch between > management app and debugging interface back and forth. > Can gdb issue monitor commands? -- error compiling committee.c: too many arguments to function