From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41176 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pulra-00079Q-3m for qemu-devel@nongnu.org; Wed, 02 Mar 2011 08:13:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PulrY-0006q0-Db for qemu-devel@nongnu.org; Wed, 02 Mar 2011 08:13:09 -0500 Received: from e37.co.us.ibm.com ([32.97.110.158]:50505) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PulrY-0006pT-8S for qemu-devel@nongnu.org; Wed, 02 Mar 2011 08:13:08 -0500 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p22DAURk016154 for ; Wed, 2 Mar 2011 06:10:30 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p22DD4dB100402 for ; Wed, 2 Mar 2011 06:13:04 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p22DD3X3010229 for ; Wed, 2 Mar 2011 06:13:04 -0700 Message-ID: <4D6E425C.8080809@linux.vnet.ibm.com> Date: Wed, 02 Mar 2011 07:13:00 -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> In-Reply-To: <4D6E19B5.6040203@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 04:19 AM, Jes Sorensen wrote: > On 02/28/11 18:44, Anthony Liguori wrote: >> On Feb 28, 2011 10:44 AM, "Jes Sorensen" wrote: >>>> Separating host-side virtagent and other tasks from core QEMU >>>> ============================================================= >>>> >>>> To improve auditing of the core QEMU code, it would be ideal to be >>>> able to separate the core QEMU functionality from utility >>>> functionality by moving the utility functionality into its own >>>> process. This process will be referred to as the QEMU client below. >> Separating as in moving code outside of qemu.git, making code optionally >> built in, making code optionally built in or loadable as a separate >> executable that is automatically launched, or making code always built >> outside the main executable? >> >> I'm very nervous about having a large number of daemons necessary to run >> QEMU. I think a reasonable approach would be a single front-end daemond. >> >> Once QAPI is merged, there is a very incremental approach we can take for >> this sort of work. Take your favorite subsystem (like gdbstub or SDL) and >> make it only use QMP apis. Once we're only using QMP internally in a >> subsystem, then building it out of the main QEMU and using libqmp should be >> fairly easy. > > Hi Anthony, > > Back from a day off playing with power drills and concrete walls :) > > Sorry I should have made it a little more clear, it was obvious to me, > but not written down: > > The idea is to keep everything as part of the QEMU package, ie. part of > qemu.git. My idea is really to have one QEMU host daemon and one QEMU > client, which provides the various services. You type make and you get > two binaries instead of one. We could allow other daemons to connect to > the host daemon, but that wouldn't be a primary target for this in my > book, and I am not sure we really want to do this. > > 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. > > I hope this clarifies things. > > Cheers, > Jes