Re: [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async

[Gerd Hoffmann <kraxel@redhat.com>]

On 03/06/12 08:56, Alon Levy wrote:
> On Tue, Mar 06, 2012 at 08:36:34AM +0100, Gerd Hoffmann wrote:
>>   Hi,
>>
>>>> How would the parallel execution facility be opaque to the implementer?
>>>> screendump returns, screendump_async needs to pass a closure. You can
>>>> automatically generate any amount of code, but you can only have a
>>>> single function implementation with longjmp/coroutine, or having a
>>>> saparate thread per command but that would mean taking locks for
>>>> anything not trivial, which avoids the no-change-to-implementation. Is
>>>> this what you have in mind?
>>>
>>> It would not be opaque to the implementer.  But it would avoid
>>> introducing new commands and events, instead we have a unified mechanism
>>> to signal completion.
>>
>> Ok.  We have a async mechanism today: .mhandler.cmd_async = ...
>>
>> I know it has its problems like no cancelation and is deprecated and
>> all.  But still: how about using it as interim until QAPI-based async
>> monitor support is ready?  We could unbreak qxl screendumps without
>> having to introduce a new (but temporary!) screendump_async command +
>> completion event.
> 
> Actually, I'm not sure this doesn't reintroduce the original problem
> (which I haven't been able to reproduce):
> 
> client: screenshot <-> client libvirt <-> host libvirt
> 
> host libvirt (screendump) <-> qemu monitor -> <- spice server <-> client

Hmm?  spice client can ask for a screendump via libvirt?

/me looks completely puzzled.

cheers,
  Gerd