[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback
From: |
Alon Levy |
Subject: |
Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback |
Date: |
Mon, 20 Feb 2012 14:36:28 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Feb 20, 2012 at 12:32:44PM +0100, Gerd Hoffmann wrote:
> On 02/19/12 22:28, Alon Levy wrote:
> > This changes the behavior of the monitor command. After the previous
> > patch, there is no longer an option of deadlock with virt-manager, but
> > ppm_save is called too early, before the update has completed. With this
> > patch it is called at the correct moment, but that means there is a race
> > between the monitor command completing and the screendump file being saved.
> >
> > The only solution is to use an asynchronous monitor command. For a
> > previous round of this see:
> > http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02810.html
> >
> > Since that's contentious, I'm suggesting we do something that is almost
> > correct and doesn't hang, instead of correct and hangs. The screendump
> > user can inotify on the directory and the file if need be. For casual
> > monitor usage there is no difference.
>
> Hmm, that is pretty lame. There are users like autotest which expect
> the screen dump being there when the monitor command is finished, that
> change will break them.
>
> Unfortunaly there is no easy way out. I think the options are:
>
> (1) Keep existing behavior. That means the screenshot might show old
> screen content. Not very nice too. Would work sort-of ok for
> autotest though as autotest does screenshots every second and thus
> the screen content wouldn't be older than a second.
>
> (2) Async monitor command. Keeps interface and works nicely. A bunch
> of QAPI bits tickled into master meanwhile, so we could look at
> this again. Luiz? What is the status here?
>
> (3) Something like this patch + additionally introduce a
> "your-screenshot-is-finished-now" qmp event. Will break existing
> users too. But at least they can be adapted without requiring
> some external, nonportable service like inotify ...
>
I was going to look for QAPI bits after this series (i.e. (2)). Doing
(3) is also possible.
> cheers,
> Gerd
>
- Re: [Qemu-devel] [RFC 7/7] qxl: add allocator, (continued)
- Re: [Qemu-devel] [RFC 7/7] qxl: add allocator, Gerd Hoffmann, 2012/02/20
- Re: [Qemu-devel] [RFC 7/7] qxl: add allocator, Alon Levy, 2012/02/20
- Re: [Qemu-devel] [RFC 7/7] qxl: add allocator, Gerd Hoffmann, 2012/02/20
- Re: [Qemu-devel] [RFC 7/7] qxl: add allocator, Alon Levy, 2012/02/20
- Re: [Qemu-devel] [RFC 7/7] qxl: add allocator, Gerd Hoffmann, 2012/02/21
- Re: [Qemu-devel] [RFC 7/7] qxl: add allocator, Alon Levy, 2012/02/21
- Re: [Qemu-devel] [RFC 7/7] qxl: add allocator, Gerd Hoffmann, 2012/02/21
- Re: [Qemu-devel] [RFC 7/7] qxl: add allocator, Alon Levy, 2012/02/21
[Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback, Alon Levy, 2012/02/19
- Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback, Gerd Hoffmann, 2012/02/20
- Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback, Eric Blake, 2012/02/20
- Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback, Alon Levy, 2012/02/21
- Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback, Eric Blake, 2012/02/21
- Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback, Alon Levy, 2012/02/21
- Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback, Luiz Capitulino, 2012/02/22
- Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback, Alon Levy, 2012/02/22
- Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback, Luiz Capitulino, 2012/02/22
- Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback, Gerd Hoffmann, 2012/02/22
- Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback, Alon Levy, 2012/02/22