From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7ji5-0002Ry-Kf for qemu-devel@nongnu.org; Wed, 14 Mar 2012 04:37:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7jhy-0003Ij-EN for qemu-devel@nongnu.org; Wed, 14 Mar 2012 04:37:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26200) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7jhy-0003II-6k for qemu-devel@nongnu.org; Wed, 14 Mar 2012 04:37:22 -0400 Date: Wed, 14 Mar 2012 08:37:13 +0000 From: "Daniel P. Berrange" Message-ID: <20120314083713.GA26510@redhat.com> 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> <4F605376.1050703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F605376.1050703@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 4/5] console: pass Monitor to vga_hw_screen_dump/hw_vga_dump Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, Luiz Capitulino On Wed, Mar 14, 2012 at 09:14:46AM +0100, Gerd Hoffmann wrote: > 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. This would not be a problem from libvirt's POV - we don't really want a file on disk anyway, nor do we want to pull the whole image into memory. Our ideal approach is to just have an pipe FD with QEMU, which we just incrementally read image data from, and forward to the client app via a libvirt stream object. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|