On 18/03/15 19:05, Anil Madhavapeddy wrote:
This fits in with a couple of things I hope to make time to work on in the next couple of months:1. Introspection of Rump Kernel domUs for ops purposes, i.e. get some basic "ps", "top", "vmstat"-like information about what the domU is doing from the dom0. 2. Connecting up multiple Rump Kernel domUs and/or Mirage domUs. The general idea here is that you can have e.g. a Mirage domU running a HTTP+TLS frontend, communicating with a Rump Kernel domU running PHP + FastCGI. The Mirage folks are already doing something similar in their Jitsu work, using a protocol called Conduit which runs over vchan.Yeah, this is currently requiring a couple of things: - kicking the tires with Vchan and its associated machinery, which has taken some time. Dave Scott has built a complementary system for the xentropyd which simply sets up a console ring instead of vchan. This has the drawback of being a single fixed page, but far simpler. - A XenStore protocol for setting up stream connections. This could indeed quite easily turn into a AF_VCHAN that could be transparently used by rump/Mirage/HaLVM and normal domUs for VM<->VM comms.
This is not an argument for or against; if you want to expose AF_WHATEVER to applications running on a rump kernel, you need to sell AF_WHATEVER to NetBSD, not to rumpkernel-users. Well, preferably you need to sell it to everyone implementing sockets and running on some sort of hypervisor, but of course gotta start from somewhere.
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
