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

[Jes Sorensen <Jes.Sorensen@redhat.com>]

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