qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Alon Levy <alevy@redhat.com>
Cc: kraxel@redhat.com, Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async
Date: Mon, 5 Mar 2012 16:45:17 -0300	[thread overview]
Message-ID: <20120305164517.4aace404@doriath.home> (raw)
In-Reply-To: <20120305185808.GE20937@garlic.tlv.redhat.com>

On Mon, 5 Mar 2012 20:58:08 +0200
Alon Levy <alevy@redhat.com> 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 <anthony@codemonkey.ws> 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	other threads:[~2012-03-05 19:45 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-05 14:16 [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async Alon Levy
2012-03-05 14:16 ` [Qemu-devel] [PATCH v2 2/2] add qmp screendump-async Alon Levy
2012-03-05 14:33 ` [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async Anthony Liguori
2012-03-05 15:17   ` Alon Levy
2012-03-05 15:56   ` [Qemu-devel] [PATCH v3 0/3] screendump async command Alon Levy
2012-03-05 15:56     ` [Qemu-devel] [PATCH v3 1/3] monitor, console: add QEVENT_SCREEN_DUMP_COMPLETE Alon Levy
2012-03-05 15:56     ` [Qemu-devel] [PATCH v3 2/3] console: add hw_screen_dump_async Alon Levy
2012-03-05 15:56     ` [Qemu-devel] [PATCH v3 3/3] add qmp screendump-async Alon Levy
2012-03-05 17:17     ` [Qemu-devel] [PATCH v3 0/3] screendump async command Anthony Liguori
2012-03-05 17:20   ` [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async Avi Kivity
2012-03-05 17:27     ` Anthony Liguori
2012-03-05 17:29       ` Avi Kivity
2012-03-05 17:56         ` Luiz Capitulino
2012-03-05 18:16         ` Anthony Liguori
2012-03-05 18:22           ` Avi Kivity
2012-03-05 19:32             ` Anthony Liguori
2012-03-05 17:31       ` Luiz Capitulino
2012-03-05 18:09         ` Alon Levy
2012-03-05 18:17           ` Avi Kivity
2012-03-05 18:58             ` Alon Levy
2012-03-05 19:45               ` Luiz Capitulino [this message]
2012-03-06  7:36             ` Gerd Hoffmann
2012-03-06  7:43               ` Alon Levy
2012-03-06  7:56               ` Alon Levy
2012-03-06  8:10                 ` Gerd Hoffmann
2012-03-06  9:35                   ` Alon Levy
2012-03-06 12:24               ` Luiz Capitulino
2012-03-06 13:16                 ` Alon Levy
2012-03-06 13:51                   ` Anthony Liguori
2012-03-06 13:53                     ` Luiz Capitulino
2012-03-06 14:23                       ` Alon Levy
2012-03-06 15:07                         ` Anthony Liguori
2012-03-06 15:56                     ` Alon Levy
2012-03-06 16:02                       ` Alon Levy
2012-03-06 16:16                       ` Anthony Liguori
2012-03-06 16:26                         ` Alon Levy
2012-03-06 16:47                           ` Anthony Liguori
2012-03-07  6:57                         ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120305164517.4aace404@doriath.home \
    --to=lcapitulino@redhat.com \
    --cc=alevy@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).