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

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

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