From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M3nfY-0001Zn-PL for qemu-devel@nongnu.org; Tue, 12 May 2009 04:49:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M3nfT-0001ZH-PO for qemu-devel@nongnu.org; Tue, 12 May 2009 04:48:59 -0400 Received: from [199.232.76.173] (port=34552 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M3nfT-0001ZE-GX for qemu-devel@nongnu.org; Tue, 12 May 2009 04:48:55 -0400 Received: from mx2.redhat.com ([66.187.237.31]:47165) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M3nfT-0002KX-09 for qemu-devel@nongnu.org; Tue, 12 May 2009 04:48:55 -0400 Message-ID: <4A0937F2.3050205@redhat.com> Date: Tue, 12 May 2009 11:48:50 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2) References: <1239215702-23818-1-git-send-email-aliguori@us.ibm.com> <1242075280.29194.117.camel@slate.austin.ibm.com> <4A089DFF.6000203@us.ibm.com> In-Reply-To: <4A089DFF.6000203@us.ibm.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: Anthony Liguori Cc: libvir-list@redhat.com, Jan Kiszka , qemu-devel@nongnu.org, Hollis Blanchard , "Richard W.M. Jones" Anthony Liguori wrote: > Hollis Blanchard wrote: >> On Wed, 2009-04-08 at 13:34 -0500, Anthony Liguori wrote: >> >>> Right now only one monitor device can be enabled at a time. In >>> order to support >>> asynchronous notification of events, I would like to introduce a >>> 'wait' command >>> that waits for an event to occur. This implies that we need an >>> additional >>> monitor session to allow commands to still be executed while waiting >>> for an >>> asynchronous notification. >>> >> >> Was there any consensus reached in this thread? I'm once again looking >> for ways to communicate qemu watchdog events to libvirt. >> > > We can do multiple monitors as a debugging tool, but to support > events, a proper machine monitor mode is a prerequisite. > > The real requirement is that events are obtainable via a single > communication channel instead of requiring two separate communication > channels. Internal implementation will look at lot like these patches. > > The reasoning for requiring a single channel is that coordinating > between the two channels is expected to be prohibitively difficult. > To have a single channel, we need a machine mode. It cannot be done > in a human readable fashion. > > I think this summarizes the consensus we reached. I don't agree fully > with the above but I'm okay with it. If you don't agree with it, it isn't a consensus. > Would you agree Avi? It represents my views fairly accurately. I'm not convinced that you can't to event notifications without machine mode, but on the other hand I do think introducing machine mode and layering notifications on top of that is the best way to proceed, so I can't complain. -- error compiling committee.c: too many arguments to function