Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features

[Michael Roth <mdroth@linux.vnet.ibm.com>]

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"<Jes.Sorensen@redhat.com>  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