From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7o2c-0002pF-SB for qemu-devel@nongnu.org; Wed, 14 Mar 2012 09:15:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7o2B-0002li-3z for qemu-devel@nongnu.org; Wed, 14 Mar 2012 09:14:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26425) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7o2A-0002lc-Sk for qemu-devel@nongnu.org; Wed, 14 Mar 2012 09:14:31 -0400 Date: Wed, 14 Mar 2012 10:14:31 -0300 From: Luiz Capitulino Message-ID: <20120314101431.5ca78105@doriath.home> In-Reply-To: <4F60842C.4020107@redhat.com> References: <00c1eea5-ccb2-4b54-89f8-bdbf00fdc8a4@zmail17.collab.prod.int.phx2.redhat.com> <4F5F48F9.7090501@redhat.com> <4F60842C.4020107@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH/RFC 0/7] Screendump to UNIX socket & in PNG format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, =?ISO-8859-1?B?TWFyYy1BbmRy6Q==?= Lureau , Gerd Hoffmann , =?ISO-8859-1?B?TWFyYy1BbmRy6Q==?= Lureau , =?ISO-8859-1?B?TWFyYy1BbmRy6Q==?= Lureau On Wed, 14 Mar 2012 12:42:36 +0100 Kevin Wolf wrote: > Am 14.03.2012 10:42, schrieb Stefan Hajnoczi: > > On Tue, Mar 13, 2012 at 1:17 PM, Gerd Hoffmann wrot= e: > >> Hi, > >> > >>> If you want to do it as part of the QEMU codebase then a thread is > >>> probably the best way - it avoids the troubles of forking a > >>> multithreaded program and letting go of resources (guest memory, file > >>> descriptors) that aren't needed across fork. > >> > >> That pretty much requires async monitor command support though, so the > >> iothread can continue driving guest i/o while the new worker thread > >> scales/compresses/writes the screendump. > >=20 > > 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. >=20 > Saving PNGs would be useful even without a management tool. =46rom HMP you mean? This should be possible, the HMP implementation could save the image received via fd to a file.