From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Lucina Subject: Re: Upstream QEMU based stubdom and rump kernel Date: Thu, 19 Mar 2015 09:48:43 +0100 Message-ID: <20150319084843.GC18697@nodbug.moloch.sk> References: <20150317142907.GD27314@zion.uk.xensource.com> <20150318112014.GC17247@nodbug.moloch.sk> <4558D0C0-8058-4052-994C-6138406CEB35@recoil.org> <5509DEB5.8060906@iki.fi> <21C9D78E-641F-46B7-9820-0C6426B533A1@recoil.org> <5509F72B.8010304@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <5509F72B.8010304@iki.fi> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Antti Kantee Cc: David Scott , Wei Liu , Ian Campbell , Stefano Stabellini , Anil Madhavapeddy , Ian Jackson , Richard Mortier , xen-devel@lists.xen.org, rumpkernel-users@freelists.org, Thomas Gazagnaire , Anthony PERARD List-Id: xen-devel@lists.xenproject.org pooka@iki.fi said: > Where do you propose to inject that faking out (and what does it > even mean)? Someone at Berkeley decided that socket drivers should > be globally enumerated, and PF_UNIX leads to exactly one handler. > Just hacking hooks as local patches into the PF_UNIX driver is > against the whole point of having unmodified, tested drivers from > upstream. We do not want to "hack hooks as local patches into the PF_UNIX driver". Rather, we'd like to develop an entirely new driver (nothing wrong with that?), which would mimic PF_UNIX semantics but talk to hyperspace instead. See below for the purpose we want to use it for. > So, if you want your bus to appear as a socket to userspace, I don't > see any shortcut to not going via NetBSD. If you're happy with > something else than a socket, that's another story. > > Especially if the interface doesn't matter too much for whatever > purpose you plan to use it for, it's silly to specify the interface > so that the implementation process is as convoluted as possible ;) By "faking out" Anil means a shim to get existing applications which currently use PF_UNIX (and possibly PF_INET, though that will be harder to fake) to use the hypervisor bus to talk to another colocated unikernel instead. The motivations for this are: - Taking the TCP stack out of the picture entirely for intra-unikernel comms (eg. PHP unikernel <-> MySQL unikernel). Both of those could be thus be linked without the PF_INET component. - This means that you do not need to set up and manage a TCP network in your infrastructure for intra-unikernel comms, which is a huge advantage from an operations point of view. - It also means that unikernels which should not be talking TCP to anywhere, ever, can't do that. Anil, have I missed anything? So, the interface does matter in the sense that it should be as simple as possible to take an existing application and get it to use the new bus. This could be as simple as linking your unikernel against -lrumpnet_hyper instead of -lrumpnet_local. Taking a longer-term view, I do think that there is a wider case for PF_HYPER and I will be happy to sell it to NetBSD (or whoever) once we are ready to make that case. In my mind the semantics of PF_HYPER from an application PoV are pretty clear: exactly the same as PF_UNIX except that you substitute "filesystem path" for "hyperspace path", with the exact semantics of "hyperspace path" left up to your hypervisor. The application need not care, as long as you can tell it to e.g. use "vchan/mysql" instead of "/tmp/mysql.sock" when doing bind(). Martin