From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41215 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pulwd-0003Eu-0X for qemu-devel@nongnu.org; Wed, 02 Mar 2011 08:18:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pulwb-0007w4-U6 for qemu-devel@nongnu.org; Wed, 02 Mar 2011 08:18:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43706) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pulwb-0007vj-LL for qemu-devel@nongnu.org; Wed, 02 Mar 2011 08:18:21 -0500 Message-ID: <4D6E4392.7010904@redhat.com> Date: Wed, 02 Mar 2011 14:18:10 +0100 From: Jes Sorensen MIME-Version: 1.0 Subject: Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features References: <4D6BD085.8000001@redhat.com> <4D6E19B5.6040203@redhat.com> <4D6E425C.8080809@linux.vnet.ibm.com> In-Reply-To: <4D6E425C.8080809@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: Juan Quintela , Dor Laor , QEMU Developers , Anthony Liguori , Gerd Hoffmann , Adam Litke , Amit Shah On 03/02/11 14:13, Michael Roth wrote: > On 03/02/2011 04:19 AM, Jes Sorensen wrote: >> It is absolutely vital for me that we do not make things much more >> complicated for users with this move. I don't want to get into a >> situation where we start forcing external packages or daemons in order >> to run basic QEMU. If we start requiring such, we have failed! However, >> I think it is a reasonable compromise to have one daemon you launch, and >> then a simple client you launch straight after which will then provide >> the same/similar views and interfaces that users are used to when they >> launch current QEMU (monitor, vnc server etc). > > I think the challenge with this approach is defining an IPC mechanism > that is robust enough to support it. For instance, on one end of the > spectrum we have Spice, where shared memory paired with some mechanism > for IO notification between the client/server might make sense. But then > we have things like the human monitor where a socket interface or pipe > is clearly more the more straight-forward route. > > We may find that it more desirable to have multiple classes of client > components, each contain within a client process with it's own IPC > mechanism. Although, multiple IPC mechanisms doesn't sound particularly > enticing either...but 2 might not be so unreasonable. Hi Michael, 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. Cheers, Jes