Re: [Qemu-devel] [PATCH/RFC 0/7] Screendump to UNIX socket & in PNG format

[Alon Levy]

On Wed, Mar 14, 2012 at 10:13:19AM -0300, Luiz Capitulino wrote:
> On Wed, 14 Mar 2012 10:01:15 +0000
> Stefan Hajnoczi <address@hidden> wrote:
> 
> > On Wed, Mar 14, 2012 at 9:51 AM, Gerd Hoffmann <address@hidden> wrote:
> > >  Hi,
> > >
> > >> The most practical first step would be simply sending the ppm over a
> > >> socket from ppm_save().  The 'screendump' command today already blocks
> > >> so no new badness is being added.  There would be no threads or fancy
> > >> image encoding.
> > >
> > > Adding scaling / compression support will add more overhead though, so
> > > doing that without offloading screendump to a thread first is a bad idea
> > > I think.  Or at least have some numbers to see how bad it actually is.
> > 
> > I agree, that's why I suggest sending the ppm over a socket.  It
> > transports out the image data and QEMU itself doesn't do the
> > encoding/scaling.
> 
> Just out of curiosity, are we planning to extend the current screendump
> command or add a new one?
> 
> If we just extend the current command, then we'll have to make the
> "filename" parameter optional. But this is a compatible change, I think.
> 
> Also, when returning the image via fd, we could offload its writing to
> a bh. This would give us a poor man's async support, where the biggest
> drawback would the lack of error detection (can this operation fail anyway?).
> 

It leaves detection of completion up to the user, so inotify / parsing
the file to see if it's complete (header says size X, but file is still
Y<X, not done..), which looks like as big a drawback.