Re: Upstream QEMU based stubdom and rump kernel

[Martin Lucina <martin@lucina.net>]

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