Hi Anthony, > This was already done in a hypervisor neutral way using virtio: > > http://lists.openwall.net/netdev/2008/12/14/8 > > The concept was Nacked and that led to the abomination of > virtio-serial. If an address family for virtualization is on the > table, we should reconsider AF_VMCHANNEL. I finally had a look at your patch. Please correct me if I'm wrong, but it seems that the peer of an AF_VMCHANNEL connection is a virtio channel inside the hypervisor, i.e., the other end is _not_ sockets, right? That's quite a bit different from vSockets, where both sides use the socket interface, even within the VMX process in our hypervisor. We also intend for arbitrary host processes -- those outside the hypervisor -- to use it via the sockets interface. We have shipping applications that do just that, where communication is between a guest process and a host service, with both sides using the standard socket API but with the vSockets address family. We also encourage people to write such VM-to-host applications, and we've been shipping the vSockets header in our host-side products to allow people to do just that. So I think in that sense vSockets is somewhat more general, and we'd obviously prefer to go with our socket family and address structure if LKML is open to something like this. Thanks! - Andy PS I realize we still owe LKML a spec for the vSockets protocol. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
