From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=52126 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Pv8bS-0002H0-Dt
	for qemu-devel@nongnu.org; Thu, 03 Mar 2011 08:30:07 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Jes.Sorensen@redhat.com>) id 1Pv8bL-0008KB-HD
	for qemu-devel@nongnu.org; Thu, 03 Mar 2011 08:30:01 -0500
Received: from mx1.redhat.com ([209.132.183.28]:41351)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Jes.Sorensen@redhat.com>) id 1Pv8bL-0008Jx-7d
	for qemu-devel@nongnu.org; Thu, 03 Mar 2011 08:29:55 -0500
Message-ID: <4D6F97C4.7010100@redhat.com>
Date: Thu, 03 Mar 2011 14:29:40 +0100
From: Jes Sorensen <Jes.Sorensen@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] QEMU: Discussion of separating core functionality
	vs supportive features
References: <4D6BD085.8000001@redhat.com>
	<AANLkTik-9oDv2UyRzVQQtKNumJnVT9pp_0U_5z+A9PSv@mail.gmail.com>
	<4D6E19B5.6040203@redhat.com> <4D6E425C.8080809@linux.vnet.ibm.com>
	<4D6E4392.7010904@redhat.com> <4D6E4B03.6000105@linux.vnet.ibm.com>
In-Reply-To: <4D6E4B03.6000105@linux.vnet.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
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>

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