qemu-devel
[Top][All Lists]
Advanced

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

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


From: Alon Levy
Subject: Re: [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async
Date: Mon, 5 Mar 2012 20:09:58 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Mar 05, 2012 at 02:31:42PM -0300, Luiz Capitulino wrote:
> On Mon, 05 Mar 2012 11:27:07 -0600
> Anthony Liguori <address@hidden> wrote:
> 
> > On 03/05/2012 11:20 AM, Avi Kivity wrote:
> > > On 03/05/2012 04:33 PM, Anthony Liguori wrote:
> > >>
> > >>
> > >> async in QEMU doesn't mean "generate a QMP event when you're done".
> > >> It should mean execute this closure when you finish (function pointer
> > >> + opaque).
> > >>
> > >> The QMP event should be dispatched from the closure such that the
> > >> screendump code doesn't have to have a direct dependency on QMP.
> > >>
> > >
> > > What about using the parallel execution facility of qmp?  It's silly to
> > > duplicate every command X with X-async and X-COMPLETED.

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?

> > 
> > We need to switch over to QAPI to get there.  We're pretty close to being 
> > there. 
> >   Luiz, about how long do you think before we get there?
> 
> It's a bit hard to tell, because it depends on upstream review plus me not
> being bogged down with other stuff. But maybe in around two weeks when I
> resume my work on this.
> 



reply via email to

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