On 06/01/16 11:41, Martin Lucina wrote:
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)
If you're worried about not being able to specify the default, the right
change is to fix runmode to be accepted without & or |, and not to start
renaming terms. Among other things, renaming closes the door for easily
adding consistent file descriptor manipulation. For example, like I
mentioned in the original mail, my proof-of-concept implementation
should be augmented to make it possible to select piping stdout or
stderr or both. Example use case: you pipe output to a vchan
communication program which forwards the output out of the guest for
further processing, use or analysis. Depending on the use case/program,
stderr might be relevant or it might not be. The syntax for specifying
what to redirect has already been invented, I don't want to see terms
such pipe_with_stderr or pipe_no_stdout to replace syntax instantly
recognizable to most likely everyone who needs to deal with the config
layer.
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.
No, there can be only one [way to specify things].
Furthermore, since above you were concerned about default parameters,
for the sake of consistency of your argumentation, what would be the
default (empty) for args[]? (one could even wonder what is the explicit
end-of-argv, if one were really concerned)
Reminder-for-thought: the config format is not the usability layer. The
only thing it needs to be is not be an unusability layer (cf. rumprun
launcher).
