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.