From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48894 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PumRI-0001T2-Nk for qemu-devel@nongnu.org; Wed, 02 Mar 2011 08:50:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PumRG-0005xs-Np for qemu-devel@nongnu.org; Wed, 02 Mar 2011 08:50:04 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.141]:49293) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PumRG-0005w4-EV for qemu-devel@nongnu.org; Wed, 02 Mar 2011 08:50:02 -0500 Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p22DeGKu002383 for ; Wed, 2 Mar 2011 08:40:16 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 0D6096E8036 for ; Wed, 2 Mar 2011 08:49:59 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p22DnwWr175222 for ; Wed, 2 Mar 2011 08:49:58 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p22DnvSr026771 for ; Wed, 2 Mar 2011 10:49:58 -0300 Message-ID: <4D6E4B03.6000105@linux.vnet.ibm.com> Date: Wed, 02 Mar 2011 07:49:55 -0600 From: Michael Roth 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> <4D6E4392.7010904@redhat.com> In-Reply-To: <4D6E4392.7010904@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: Juan Quintela , Dor Laor , QEMU Developers , Anthony Liguori , Gerd Hoffmann , Adam Litke , Amit Shah On 03/02/2011 07:18 AM, Jes Sorensen wrote: > 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. 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. > > Cheers, > Jes