From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55169) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4c9S-0000UW-K8 for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:56:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4c9P-0007a5-EQ for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:56:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:11699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4c9P-0007Zs-6f for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:56:47 -0500 Date: Mon, 5 Mar 2012 14:56:46 -0300 From: Luiz Capitulino Message-ID: <20120305145646.05a860f8@doriath.home> In-Reply-To: <4F54F7EA.2010705@redhat.com> References: <1330956981-5001-1-git-send-email-alevy@redhat.com> <4F54CEA2.10808@codemonkey.ws> <4F54F5F8.70105@redhat.com> <4F54F76B.70403@codemonkey.ws> <4F54F7EA.2010705@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Alon Levy , kraxel@redhat.com, Anthony Liguori , qemu-devel@nongnu.org On Mon, 05 Mar 2012 19:29:14 +0200 Avi Kivity wrote: > On 03/05/2012 07:27 PM, Anthony Liguori wrote: > > On 03/05/2012 11:20 AM, Avi Kivity wrote: > >> On 03/05/2012 04:33 PM, Anthony Liguori wrote: > >>> > >>> > >>> async in QEMU doesn't mean "generate a QMP event when you're done". > >>> It should mean execute this closure when you finish (function pointer > >>> + opaque). > >>> > >>> The QMP event should be dispatched from the closure such that the > >>> screendump code doesn't have to have a direct dependency on QMP. > >>> > >> > >> What about using the parallel execution facility of qmp? It's silly to > >> duplicate every command X with X-async and X-COMPLETED. > > > > We need to switch over to QAPI to get there. > > Just an implementation detail, yes? No spec/protocol changes? We haven't discussed it yet how to do async commands in detail, so it may or may not have protocol changes. I have a simple proposal in mind, but haven't submitted it yet. > > We're pretty close to being there. Luiz, about how long do you > > think before we get there? > > It's a pity to add new commands along the way. We decided not to block useful features because of the long time that's taking to do async support properly.