[might be crazy] lkl on Rump kernels?

[staalmannen]

As far as I can see, the scope of lkl is pretty similar to the NetBSD Rump kernels (http://rumpkernel.org/). The difference there is that it has developed several back-ends already (directly on Xen, bare metal, GenodeOS, Hurd, ...).

So the crazy thing I just throw "out there" is : does it make any sense to build lkl on top of Rump (specifically, rumprun libc)?

At first sight it seems as convoluted as running Cygwin on top of Wine, but people do that sometimes...

[thehajime]

I think it should not go into the first upstream since it's still buggy and makes ppls think so many things at the same time, but I've already started to port my linux libos work to lkl with a rump hypercall backend.

https://github.com/thehajime/lkl-linux/tree/rump-hypcall
(I'm using non-ff update frequently at this testing moment so, each commits are tentative.)

status is really early stage and needs more effort to work on.

screencast of rumprun nolibc on qemu

the benefit of being a rump kernel is not only the support of new backends, but also other features (syscall proxy, much matured hijack implementation, etc). I will keep working on my forked branch so, see you there if you're interested in.

[thehajime]

So the crazy thing I just throw "out there" is : does it make any sense to build lkl on top of Rump (specifically, rumprun libc)?

could you care to elaborate what rumprun libc means ? rumprun-posix or else ?

[staalmannen]

I might have misunderstood Rumprun.
I thought it basically was based on a NetBSD libc that had been modified to run on top of a rump kernel. I also expected lkl to depend on libc to have correct syscalls etc on a non-linux host kernel.

[thehajime]

status update is available on my blog: thehajime/blog#1. Any comments, feedback, and patches are more than welcome !

[staalmannen]

very interesting. thanks (unfortunately too busy to play atm)