From: Jes Sorensen <Jes.Sorensen@redhat.com>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Juan Quintela <quintela@redhat.com>, Dor Laor <dlaor@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Anthony Liguori <aliguori@linux.vnet.ibm.com>,
Gerd Hoffmann <kraxel@redhat.com>, Adam Litke <agl@us.ibm.com>,
Amit Shah <amit.shah@redhat.com>
Subject: Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features
Date: Thu, 03 Mar 2011 14:29:40 +0100 [thread overview]
Message-ID: <4D6F97C4.7010100@redhat.com> (raw)
In-Reply-To: <4D6E4B03.6000105@linux.vnet.ibm.com>
On 03/02/11 14:49, Michael Roth wrote:
> On 03/02/2011 07:18 AM, Jes Sorensen wrote:
>> I think we need two types for sure, even for the video case, we will
>> still need a control channel as well. However, I don't think it is
>> desirable to split things up more than we have to, so if we can keep it
>> within one client process that is good. Maybe there are cases where it
>> makes sense to split it into more processes, I could be convinced, but I
>> think we really need to be careful making it too much of a complex mess
>> either.
>
> Yup, if it's doable I'd prefer a single client process as well. Just
> hard to predict how difficult it'll be to support 2 or more mechanisms.
> Although, I'd imagine we'd end up with something like qemu's io loop,
> with event-driven shmem and fd-based work, which does seem doable.
That is pretty much what I had in mind. Will have to see how it works
out, but I think it is very feasible :)
Cheers,
Jes
prev parent reply other threads:[~2011-03-03 13:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-28 16:42 [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features Jes Sorensen
2011-02-28 17:44 ` Anthony Liguori
2011-03-01 12:07 ` Dor Laor
2011-03-01 12:40 ` Anthony Liguori
2011-03-01 14:25 ` Dor Laor
2011-03-01 14:29 ` Anthony Liguori
2011-03-02 10:25 ` Jes Sorensen
2011-03-02 10:56 ` Dor Laor
2011-03-02 11:02 ` Jes Sorensen
2011-03-02 10:58 ` Alon Levy
2011-03-02 11:04 ` Dor Laor
2011-03-02 12:39 ` Alon Levy
2011-04-26 9:14 ` Gerd Hoffmann
2011-04-26 13:15 ` Anthony Liguori
2011-03-02 11:05 ` Jes Sorensen
2011-03-02 10:28 ` Jes Sorensen
2011-03-02 10:42 ` Dor Laor
2011-03-02 10:47 ` Jes Sorensen
2011-03-02 10:21 ` Jes Sorensen
2011-03-02 10:19 ` Jes Sorensen
2011-03-02 13:13 ` Michael Roth
2011-03-02 13:18 ` Jes Sorensen
2011-03-02 13:49 ` Michael Roth
2011-03-03 13:29 ` Jes Sorensen [this message]
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=4D6F97C4.7010100@redhat.com \
--to=jes.sorensen@redhat.com \
--cc=agl@us.ibm.com \
--cc=aliguori@linux.vnet.ibm.com \
--cc=amit.shah@redhat.com \
--cc=dlaor@redhat.com \
--cc=kraxel@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.