From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lrv5s-0007TD-NW for qemu-devel@nongnu.org; Thu, 09 Apr 2009 10:19:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lrv5m-0007PI-TI for qemu-devel@nongnu.org; Thu, 09 Apr 2009 10:19:03 -0400 Received: from [199.232.76.173] (port=40842 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lrv5m-0007P3-8O for qemu-devel@nongnu.org; Thu, 09 Apr 2009 10:18:58 -0400 Received: from mx2.redhat.com ([66.187.237.31]:58125) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lrv5l-0006E6-5X for qemu-devel@nongnu.org; Thu, 09 Apr 2009 10:18:58 -0400 Message-ID: <49DE03F0.6070503@redhat.com> Date: Thu, 09 Apr 2009 17:19:28 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2) References: <1239215702-23818-1-git-send-email-aliguori@us.ibm.com> <49DDAF9F.7040400@redhat.com> <49DDF807.1050707@us.ibm.com> <49DDFAD5.7060808@redhat.com> <49DDFC5C.4080504@us.ibm.com> <49DE0042.9050103@redhat.com> <49DE0303.7070507@redhat.com> In-Reply-To: <49DE0303.7070507@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: libvir-list@redhat.com, Anthony Liguori , Jan Kiszka , qemu-devel@nongnu.org, Hollis Blanchard Gerd Hoffmann wrote: > On 04/09/09 16:03, Avi Kivity wrote: >> I don't want multiplexed monitor sessions, at all. > > I'm very happy to finally see them. Finally one can run vms with > libvirt and *still* access the monitor for debugging and development > purposes. > Right, I like them for that purpose as well. But not for ordinary control. >> I want async >> notifications added to a single monitor session. That too could be >> implemented today (as simple as a term_printf("notification: ...\n"); > > No. It is simple on the qemu side only. Parsing notifications poping > up at random places in the stream is more complex. I don't understand why, if there's a common prefix. Everywhere you expect (qemu), also expect notification:. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.