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: Luiz Capitulino
Subject: Re: [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async
Date: Mon, 5 Mar 2012 16:45:17 -0300

On Mon, 5 Mar 2012 20:58:08 +0200
Alon Levy <address@hidden> wrote:

> On Mon, Mar 05, 2012 at 08:17:52PM +0200, Avi Kivity wrote:
> > On 03/05/2012 08:09 PM, Alon Levy wrote:
> > > 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?
> > 
> > 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.
> 
> Yeah, that sounds good. Let's have that for 6.4.

That's too far away, qemu will have be re-written a dozen of times when we
get there.

But if you meant 1.2, yes, I hope to have async support for 1.2. But I must
admit that I'm having some trouble delivering things on time...



reply via email to

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