Re: initial support for multiple "executables" in a single unikernel
- From: Martin Lucina <martin@xxxxxxxxxx>
- To: rumpkernel-users@xxxxxxxxxxxxx
- Date: Tue, 16 Jun 2015 12:03:47 +0200
On Monday, 08.06.2015 at 23:43, Antti Kantee wrote:
Current limitations:
1) does not deal with symbol collisions in progs (should be easy to fix?)
2) all programs get the same argv (a bit harder to fix?)
3) there is no "job control"/"rc script", i.e. you can't say e.g.
"run prog1 first, and only when it exits run prog2 and prog3 in
parallel" (ditto)
4) the implementation is bit ugly (the ugliness is not exported,
so it's in the "easy problems" category)
5) the "break main" debugging idiom works only for main() of prog1
(this probably can't really be fixed, but perhaps there's some trick
to make it more obvious how to break at the entrypoint of prog[n])
Eventually, especially after figuring out "2" and "3", multiprogram
support will give the ability to bake command utilities into
unikernels so that we don't have to reimplement complicated command
utilities, e.g. firewalls, in rumpconfig, or rely on rumpctrl to
externally handle configuration. I've been talking about that for
at least a year, so it would be nice to get it finally done. If
working on some of the above issues is interesting to someone, I'm
happy to donate things from my plate.
While this is an impressively minimal approach to accomplishing your stated
long-term goal (re-use of existing command line utilities for configuration
of unikernels) and short-term goal (helping with development and testing),
I'm concerned about two points:
1) "marketing" this as a first-class feature will give people the wrong
idea about what it is intended for. Someone will bake PHP and nginx into a
single unikernel and then get upset when PHP stomps all over their nginx.
2) figuring out your points 2) and 3) sounds suspiciously like implementing
a shell. One of the major points I'm emphasising when I speak of unikernels
is that there is no such thing as a shell, and thus your run-of-the-mill
exploits cannot exec() arbitrary commands. Granted, in this case you still
cannot execute *arbitrary* commands, but this feels like a step in that
direction.
When I spoke with Justin in Cambridge, he made the point that the set of
command line utilities required to configure unikernels is quite small, and
that a better approach would be to (semi-manually?) "librarise" the
required utilities.
Justin? Thoughts?
Other related posts:
