> > > Our position is that VSOCK feature set is more complete and that > > > it > > > should be possible to use transports other than VMCI for VSOCK > > > traffic, should interested parties implement them, > > > > Implementing other transports requires restructing vsock (and vmci) > > first as the current vsock code is not a hypervisor neutral > > service. > > I'm going to bite the bullet and spend the next couple of days doing > just that: factoring out the VMCI bits and hiding them behind a > transport layer. It'll be a bit rough, but it'll be a start. We'll > submit another patch series next week with that. I'm hoping that'll > get us over this hump, since it should by hypervisor agnostic at > that point. It'll be up to you guys to add virtio, though :)
I sent out a patch series this morning that splits out our code into a core part, containing the socket family/operations, and a VMCI-specific part. The core makes callbacks via a new transport layer into VMCI. It's not perfect -- there's still some cruft in the core socket structure -- but it lays the foundation of a hypervisor-neutral channel, and hopefully we can build on this with your help. It'd be great if you could take a look. Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
