On 24/05/15 16:41, Anil Madhavapeddy wrote:
Good show! Supporting existing platforms and applications while
enabling things to be done better where it matters most is a true
realization of the rump kernel slogan "you can make an omelette
without breaking the kitchen".
That said, can you expand on the motivations behind your work with a
paragraph or so? I don't recall the project being introduced at
least on the rump kernel kernel list, and I while can guess the
motivations, I'd rather not guess if I don't have to ;)
The Mirage folks have built a green-field implementation of a TCP/IP, TLS
and HTTP stack, all in memory-safe OCaml. What I'd like to get to is
being able to build systems which use the best of both worlds. For example,
have a Mirage unikernel serve TLS and/or HTTP, and talk FastCGI to a PHP
backend running on a rumprun unikernel.
The other interesting aspect is using Jitsu [1] to spawn just-in-time
unikernels on demand. This would let you have a bunch of unikernels which
are dormant and are only booted when the service they provide is actually
accessed.
The other reason that this is so useful is that it opens up the other
non-Xen backends to Mirage (such as KVM) in the short term. In the longer
term, we'd replace the virtio drivers with type-safe equivalents, but its
useful to be able to boot on KVM with the Rump drivers to get started
and have a stable point.
In general, the mixing of new type-safe drivers in Mirage/HaLVM and
newer languages such as Rust, combined with the stable Rump NetBSD drivers
is a pretty compelling way to migrate towards unikernels...
This other reason is the one I see as the extremely interesting one.
It's curious, the longer the current implementation provided by rump
kernels (*) stays useful, the more disappointed I am since we have
failed to provide better options to legacy software. That said, even
with newer languages existing, I will be extremely surprised if the
current implementation will be obsolete in 10 or even 20 years -- the
Tarzan who rewrites everything in safe languages in production quality
simply doesn't exist. I do hope people try to prove me wrong, though
either way I win: either I'm right, or I have vastly better software at
my fingertips.
For users, these types of synergies are truly exciting: being able to
ride the wave of the latest omelette research while at all times having
access to a fully equipped, working kitchen. Getting more users and
deployers on board also gives us good feedback on which reality-derived
problem/component is currently in most urgent need of a solution.
*) the concept is generic, and I hope that future operatin^Wbottom
layers of the software stack will retain separation between driver
implementation and the environments the driver is usable in.
_______________________________________________
MirageOS-devel mailing list
[email protected]
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
