From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0D5K-0005at-5M for qemu-devel@nongnu.org; Wed, 22 Feb 2012 09:22:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S0D5D-0008Sw-EC for qemu-devel@nongnu.org; Wed, 22 Feb 2012 09:22:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38853) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0D5D-0008Ss-7Z for qemu-devel@nongnu.org; Wed, 22 Feb 2012 09:22:15 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1MEME7b023295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 22 Feb 2012 09:22:14 -0500 Message-ID: <4F44FA13.7080607@redhat.com> Date: Wed, 22 Feb 2012 15:22:11 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <1329686886-6853-1-git-send-email-alevy@redhat.com> <1329686886-6853-6-git-send-email-alevy@redhat.com> <4F422F5C.9060202@redhat.com> <4F42BB27.6070504@redhat.com> <20120221081948.GC6476@garlic> <4F43C331.7090000@redhat.com> <20120221174016.GO6476@garlic> <20120222111717.0c56390f@doriath.home> <20120222132250.GG607@garlic.redhat.com> <20120222114927.4c303fd0@doriath.home> In-Reply-To: <20120222114927.4c303fd0@doriath.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Eric Blake , Alon Levy , qemu-devel@nongnu.org, elmarco@redhat.com Hi, > Honestly, for this particular case, I'm not 100% sure that having an id is > _required_, as I don't expect a client to submit multiple screendump calls > in parallel and we don't "officially" support multiple QMP clients either. > Also, having the screendump filename in the event will serve as a form of > identifier too. That is exactly my thinking, echo the filename written in the event. > Btw, are you planning to add the event to the already existing screendump > command? Adding a new command that doesn't use the monitor async API and > is truly asynchronous wouldn't better? Good question. I'd tend to just let the existing command send trigger an event. But libvirt needs some way to figure whenever it should wait for an event ... cheers, Gerd