From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8A1G-0006gx-IF for qemu-devel@nongnu.org; Wed, 11 Nov 2009 05:01:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8A1B-0006Wg-Fs for qemu-devel@nongnu.org; Wed, 11 Nov 2009 05:01:41 -0500 Received: from [199.232.76.173] (port=57635 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8A1B-0006W4-8O for qemu-devel@nongnu.org; Wed, 11 Nov 2009 05:01:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60735) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8A1A-00081I-JU for qemu-devel@nongnu.org; Wed, 11 Nov 2009 05:01:36 -0500 Date: Wed, 11 Nov 2009 11:59:01 +0200 From: "Michael S. Tsirkin" Message-ID: <20091111095901.GA3387@redhat.com> References: <20090921224430.610da97b@doriath> <87my4l1e4e.fsf@pike.pond.sub.org> <20090924093146.66191c37@doriath> <4ABB69C0.1000404@redhat.com> <20090924100559.07959a7c@doriath> <4ABB6F10.4080608@redhat.com> <20090924101458.00d65388@doriath> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090924101458.00d65388@doriath> Subject: [Qemu-devel] Re: ANN: QEMU Monitor Protocol git tree List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: qemu-devel@nongnu.org, aliguori@us.ibm.com, Avi Kivity , Markus Armbruster On Thu, Sep 24, 2009 at 10:14:58AM -0300, Luiz Capitulino wrote: > On Thu, 24 Sep 2009 16:07:28 +0300 > Avi Kivity wrote: > > > On 09/24/2009 04:05 PM, Luiz Capitulino wrote: > > >>> I think the easiest way to have this would be to add a > > >>> monitor command to disable capabilities. Like a command to > > >>> disable async messages. > > >>> > > >>> > > >> Other way around, enable things that you want. > > >> > > > Ok, I will add support for this in my tree then, async messages > > > will be considered a capability. > > > > > > > Actually, if async messages are specified from day one they can be > > always active. The client can easily ignore them. > > That's also fine by me, but we were talking about having a > command to disable async messages... If we do this, I would > prefer to make it a capability instead, this way it can use > the same infrastructure (as opposed to special treatment). Maybe per message type (error/warning/info/debug). -- MST