On (Tue) Jul 28 2009 [08:42:32], Anthony Liguori wrote: > Amit Shah wrote: >> Right; use virtio just as the transport and all the interesting >> activity happens in userspaces. That was the basis with which I started. >> I can imagine dbus doing the copy/paste, lock screen, etc. actions. >> >> However for libguestfs, dbus isn't an option and they already have some >> predefined agents for each port. So libguestfs is an example for a >> multi-port usecase for virtio-serial. >> > > Or don't use dbus and use something that libguestfs is able to embed. > The fact that libguestfs doesn't want dbus in the guest is not an > argument for using a higher level kernel interface especially one that > doesn't meet the requirements of the interface. But why do we want to limit the device to only one port? It's not too complex supporting additional ones. As I see it qemu and the kernel should provide the basic abstraction for the userspace to go do its job. Why create unnecessary barriers? Amit -- 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
