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?
