> the only usage of "unikernel infrastructure" is essentially to hack around elevating privileges for networking in macOS
(author of the talk here)
That's correct, although I view that in a less dismissive light than your comment above suggests :-)
The "unikernel infrastructure" movement hinges on turning as many systems layers as we can into libraries, so that they can be repurposed in the future in different contexts. This can also include using them in _exactly_ the same way as you use systems today (e.g. compiling unikernels to Linux binaries pointing at a socket stack).
But when a problem comes along that requires challenging conventional layering, having unikernel libraries is a game changer. Without this, we would have to maintain a much more heavyweight emulation system, which in turn drives up complexity and resource usage. In the D4Mac/Win case, putting in the VPNKit library layer gives us a lot of flexibility in mapping to existing socket stacks, and also lets us open a broader conversation about what network bridging should look like in the next generation OS stack. Whatever that answer is, we know that solution isn't what we are forced to live with today -- root level privilege and importable kernel modules required to shift Ethernet packets around. Perhaps the answer is something more like FreeBSD's declarative Netgraph framework, or an OSX-style launchd socket registration system that works across higher level protocols including TLS, or something else entirely different. But until then, the unikernel infrastructure lets us solve the immediate systems problem at hand without letting that design decision vomit all over the rest of the application stack and burden us with a ton of technical debt.
> It sounds like MirageOS was only used because it was a reasonably portable network stack
It also happened to be the one that many of the team had authored, and written in a high-level enough style that we knew how to invert it. Nothing dramatic here, just picking the shortest solution to get shipping software that solved real user problems (in this case, VPN and firewall support on OSX/Win).
I expect that pulling off the same trick using several other user-level network stacks is also not hugely difficult, but I haven't used lwIP for some years to find out. The Rump Kernel NetBSD stack is probably the best alternative to start with, or the HalVM TCP/IP stack. The IncludeOS C++ one is also rapidly becoming a mature candidate.