People: Martin Lucina

Martin Lucina edited this page Dec 8, 2015 · 3 revisions
Clone this wiki locally

The stack (a.k.a. TODO list, goals and what I'm working on)

(meta)

  • Sorted in rough priority / LIFO order.
  • (in progress), (done) and (hard) mean what they say on the tin.
  • (undecided) means I don't have this item worked out in my head yet.
  • Other questions also in italics.
  • Feel free to comment, suggest PUSH/POP/SORT. If you edit, please write a helpful commit message :)

High-level goals

  • Before Christmas 2015:
    • Demo fully working Mirage + rumprun unikernel stacks, with a user-friendly tool for launch/deployment, even if limited scope. (See "autoconfiguration" and "rumprun launch tool" below.)
  • Early 2016:
    • Vchan support, so that we can eliminate TCP from the "unikernel to unikernel" communication path.
    • Get rumprun (and thus also Mirage) running properly on all the major cloud hypervisors (AWS/GCE/Azure), with a simple deployment story (see "rumprun launch tool").

Low-level TODO list

Ongoing

  • Rumprun general maintenance, bug fixing and upstream project support (list discussions, documentation, blogs, etc.).
    • Stabilise rumprun external interfaces and toolchain as much as possible, preferring removing scope to argument. ("If we can't agree how to do it, leave it out.")
    • Work out what to present and at which conferences in 2016.
    • Dogfood everything by moving my personal production services (websites, email, etc.) to unikernels where it makes sense, and blog/document the experience.

Short-term

  • (done) KVM pvclock support for rumprun.
  • (done) Docker builds of rumprun toolchain and rumprun-packages, to serve both as CI (using Docker Hub automated builds) and as one-click "get started with the toolchain" packages for Mac users.
    • Wanted to base these off Alpine Linux as the images are tiny, however rumprun is currently broken on musl toolchains due to issues with libssp, so using Debian as a base for now.
  • Mirage/Rump integration:
    • (done, see mirage/mirage#479) Document changes I made, so that @mort can look at upstreaming some of the OCaml-specific stuff.
  • (in progress) Nail down the rumprun-launch debate and rumprun unikernel configuration specification.
  • (in progress) Work on tools to manage and launch rumprun unikernels as Docker containers, based on the experience from the DCEU2015 demo (https://github.com/Unikernel-Systems/DockerConEU2015-demo)
  • Write a code generator to take the rumprun JSON config and output a C module that can be linked directly into a unikernel.
    • If this is to be merged upstream, requires refactoring the librumprun_base rumprun_boot(), rumprun_config() and related interfaces.
  • (in progress) Diskless ("baked-in filesystem") support for rumprun.
    • This will help rumprun-on-jitsu, among other things. It's also a workaround for e.g. GCE until we have virtio-scsi.
  • Mirage/Rump integration:
    • (postponed) Documented in mirage/mirage-tcpip#180. Work out how to do the rumprun (C) side of interfacing the direct TCP stack. @mort will work out the Mirage (OCaml) side.
    • Continue working with @mort and other OCaml folks on improving the port.

Medium-term

  • Collaborate with Mirage (and other unikernels?) on unifying the configuration spec.
  • (undecided) "autoconfiguration" for rumprun unikernels.
    • Goal: I want to be able to take the same unikernel image which I run locally on my laptop via $HYPERVISOR and deploy it on AWS/GCE/Azure/elsewhere. Scope is only for the simple "80% case", if you want to customize anything then you will need to use manual or JSON configuration anyway.
    • Goal: Simple deployment for newbie users.
  • (undecided) Some kind of replacement for the "rumprun" launch tool, tied in with the "autoconfiguration" use case.
    • Goal: Simplest possible UX for the developer.
  • Vchan:
    • User-visible goal: Mirage unikernel with TLS, HTTP, communicating over vchan to rumprun unikernel which has no TCP stack.
    • Internal goal: Frontend (unikernel, client) and backend (hypervisor, negotiation protocol) independent re-implementation of libvchan.
      • It should be possible for someone (not necessarily me) to implement a KVM backend, although lack of any kind of negotiation mechanism to enable direct guest to guest communication makes it kind of pointless. Perhaps port Xenstore to KVM?
    • Start by implementing just the ring buffers, a generic user-space frontend with a socket-like API and a generic user-space stub backend for testing (e.g. negotiation using PF_UNIX / POSIX shmem).
    • Implement NetBSD kernel-space frontend (for rumprun, as PF_VCHAN).
    • Implement Xen (hypervisor) and Xenstore (negotiation) backend.
    • Implement NetBSD kernel-space PF_UNIX to PF_VCHAN shim.
  • (done by @anttikantee/upstream) Port the virtio-scsi driver from FreeBSD.
    • Needed for GCE support, among others.
  • UEFI boot for rumprun.
    • Needed for Azure, should be able to prototype this on the Intel Galileo board.

Long-term/"wishlist"

  • (possibly earlier, this is a good feature for the security-paranoid crowd) Support for "sealed" unikernels in rumprun. I.e. W^X done properly on all platforms, and have a "drop privileges" hypercall for Xen which says "Guest will not map any new executable pages, ever".
    • "Drop privileges" hypercall discussed with Andy Cooper at the Xen summit, he liked it.
  • Fully integrated and tested ARM port to a suitable set of targets (e.g. RPI2, Cubieboard).
  • Support for building the rumprun toolchain natively on OSX:
    • (done by @mattg) Using a gcc ELF toolchain (should be easy).
    • Using the native Xcode/clang Mach-O toolchain (hard).
  • Figure out how to use the NetBSD drivers for Xen {blkfront, netfront, xenbus}, instead of the Mini-OS ones which are crap and unmaintained.
    • Implies full PVH support for Xen.
    • Just the PV on HVM drivers bit is fairly easy. The rest is probably (hard).
  • Merge the rumprun "hw" and "xen" platforms, thus killing the remains of Mini-OS entirely. (hard)