On Monday, 21.12.2015 at 15:25, Martin Lucina wrote: > 1. "rc": This is taken almost-unmodified from Antti's original proposal for > running multibaked binaries. However, it still relies on the *order* of > configuration entries matching up with the order of binaries baked in to > the unikernel. I think it would be worth improving this to give multibaked > binaries real names and select the binary to run based on "bin". This > could be done by implementing a posix_spawn() and using that as the > interface for spawning binaries, which would give us a public API we could > point people who want to do multi-process at.
I've pushed some small changes to "rc" on the branch: - use "bg" and "pipe" instead of "&" and "|" for runmode - allow the user to explicitly specify "fg" (thanks to Martin Sustrik for the tip -- implicit but not specifiable defaults are bad for config generation tools) Have also thought a bit more about the remaining problems with "rc" and multibake: Antti's original proposal asked the question of what to do about "argv", specifically about how to specify argv[0]. I had to make a choice there and went for the less-flexible but user-friendly approach of argv[0] == bin, argv[1..N] == args[]. This has the downside of not supporting multi-call binaries. Having thought about it, we could instead specify both argv[] and args[], but make them mutually exclusive. If the user specifies args[] then they get the current behaviour (described above). If the user specifies argv[] then the entire argv[] array gets set from this. That leaves the problem of the "rc" entries relying on the order of programs passed at rumprun-bake time. If we could use "bin" as a discriminator to identify the binary then the ordering problem goes away, and "rc" can also invoke a binary multiple times. Needs some experimentation with rumprun-bake and the linker to figure out how feasible this is. Martin
