On Mon, Jul 27, 2009 at 06:44:28PM -0500, Anthony Liguori wrote: > It really suggests that you need _one_ vmchannel that's exposed to > userspace with a single userspace daemon that consumes it. ... or a more flexible API. I don't like having fixed /dev/vmch* devices either. A long time ago (on a mailing list not so far away) there was a much better userspace API proposed, which had a separate AF_VMCHANNEL address family. That API works much more like TCP sockets, except without requiring network devices: https://lists.linux-foundation.org/pipermail/virtualization/2008-December/012383.html Note: even better if it allows multiple channels with the same name to be created on demand from the guest, which the API would allow, although not the implementation above. That would allow the fast-user-switching / multi-X-server case to work well, and be useful if we parallelize libguestfs. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
