On 03/09/15 19:29, Sebastian Wicki wrote:
Hi all,
Today I upstreamed a flag (-k) to build-rr.sh which builds the rump
kernel and libbmk_rumpuser without libc, rumprun_* or app-tools. [1]
Very cool, thanks for your contribution.
As opposed to normal rumprun unikernel use, which is in a way supposed
to be transparent for the application, the idea here is that the
client code uses the rump kernel (and platform) directly, and provides
all other code it needs itself. I've been using this for my ongoing
summer of code project. The flag excludes all the "userland"
libraries, but includes the libcompiler_rt for convenience so one can
link together a bootable image.
I'd still argue it's a unikernel, it's just not a unikernel with a POSIX
API towards the "application". But then again, Rumprun is almost the
odd one in the unikernel family for providing a POSIX API (which is now
optional ;)
There's one important point to raise: which interfaces do you think are
(or should be) stable?
Currently, only the 'hw' platform is supported. Xen needs some
additional work, as some mini-os header (mini-os/types.h) files
include some userland headers.
Yea that's going to be another session of rototilling before it's fixed,
since there still are some parts in the Xen platform code which assume
POSIX'y headers and a layer mishmash. Would be nice to fix it, but
unless someone has a use case for "nolibc" on Xen, it's not very urgent
and does no harm in its current state (and besides, when someone has a
use case, they also typically have motivation to instigate a fix).
