From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:55561)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1S7jMH-0000oS-Lk
	for qemu-devel@nongnu.org; Wed, 14 Mar 2012 04:15:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1S7jMB-0007V1-Da
	for qemu-devel@nongnu.org; Wed, 14 Mar 2012 04:14:57 -0400
Received: from mx1.redhat.com ([209.132.183.28]:3769)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1S7jMB-0007Ut-5V
	for qemu-devel@nongnu.org; Wed, 14 Mar 2012 04:14:51 -0400
Message-ID: <4F605376.1050703@redhat.com>
Date: Wed, 14 Mar 2012 09:14:46 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <1331483977-18910-1-git-send-email-alevy@redhat.com>
	<1331494004-26177-1-git-send-email-alevy@redhat.com>
	<1331494004-26177-5-git-send-email-alevy@redhat.com>
	<20120313103555.0ae4b834@doriath.home>
	<20120313144514.GK27659@garlic.redhat.com>
In-Reply-To: <20120313144514.GK27659@garlic.redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v2 4/5] console: pass Monitor to
	vga_hw_screen_dump/hw_vga_dump
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Luiz Capitulino <lcapitulino@redhat.com>, qemu-devel@nongnu.org, aliguori@us.ibm.com

  Hi,

>> Some solutions that come to my mind:
>>
>>  1. Pool the screendump file creation from a timer.
>>
>>     Cons: it may return before the file is fully written to disk
>>
> 
> We know what the file size should be, so we can poll for the actual
> size. Actually why do we need to poll? we could add a
> "internal.screendump.complete" or "internal-query-screendump", no?

Marc-Andre currently looks at adding support for other file formats.
I think it would be good to team up with him.

First, with this applied you will not know the size in advance.  Also
one of the approaches discussed is to allow passing in a file handle.
That is a possible way to handle async screendumps too: just write to
the passed file handle and close it when done.  Obvious drawback is that
this will not cover the classic way of specifying the output filename as
argument.

cheers,
  Gerd