Re: [MirageOS-devel] OCaml and Mirage now running on rumprun, including bare metal

[Antti Kantee <pooka@xxxxxxxxxxxxxx>]

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
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel