qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH/RFC 0/7] Screendump to UNIX socket & in PNG format
Date: Tue, 13 Mar 2012 11:17:57 +0000

On Tue, Mar 13, 2012 at 11:14 AM, Marc-André Lureau <address@hidden> wrote:
> Hi
>
> ----- Mensaje original -----
>> Yeah it wants png, jpeg, tiff.  What I'm concerned about is that QEMU
>> should be doing emulation/virtualization, not processing images for
>> an
>> end-user.  Its main loop is not structured to do utility tasks
>> unrelated to running the guest.  If implemented properly QEMU isn't a
>> good place to host this processing, and if done badly we block the
>> guest and make it unresponsive.  This is a general architectural
>> problem, not something specific to your proposal but this is why I'm
>> against putting this into QEMU.
>>
>> If you send a ppm over a file descriptor, what's the fundamental
>> limitation which requires you to add this code to QEMU?  Perhaps
>> simply supporting file descriptors is the right level of support from
>> QEMU.
>
> That sounds reasonable to me, I would even remove the PPM support, and the 
> format conversion in this case.
>
> It needs to be done somewhere though, and it seems reasonable to do it from 
> the source.
>
> What if we fork a subprocess (linked with gdkpixbuf) that would do the job 
> with stdin/stdout?

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.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]