qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1)


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1)
Date: Wed, 01 Jul 2009 16:32:27 -0500
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

Gerd Hoffmann wrote:

With multiple connections and multiplexing: You'll just connect, type a few commands, disconnect, done. You'll even see what you have done when you come back to the office the next day.

Also note that the vnc server accepts input from multiple clients as well, which can lead to simliar problems. Nobody wants to kill support for multiple clients just because of that, because in practice it isn't a issue.

I don't disagree with your use-case. What I'm pointing out, is that we need to do some major surgery to get there.

The current chardev protocol has no real notion of flow control and assumes a static bidirectional channel between the front-end and back-end. Flow control policy is inconsistent and those decisions are made in the back-end (i.e. tcp:).

We really need to push flow-control to be a proper part of the protocol though so that the front-end can participate. For instance, virtio-console/serial is fully capable of implementing flow control. Punting buffering policy to the guest is IMHO the best possible solution to the general problem.

Having multiple connections within a chardev really also needs to be part of the monitor protocol because it's fundamental to flow-control. We want the front-end to have enough information to know how many clients are connected and which ones are ready to receive.

When dealing with a single I/O source, it should be front-end policy to determine what to do. Certainly, there are some front-ends (like the monitor) that can support multiple I/O sources. Another example is the VNC server which really should be using chardevs.

I agree that mirroring is a pretty reasonable policy to map a single I/O source to multiple clients for some devices. That should be a front-end decision though.

In this model, I still don't see having two different back-ends connected to a single front-end. I don't know if I agree there's a whole lot of value in that although the implementation is straight forward (a special back-end that unifies multiple front-ends as sessions).

Regards,

Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]