Hi,
A long-standing issue has been that there's no way to specify args for
multibaked programs. So let's try to specify the appropriate json
config format for that. My very simple proposal, with a few open
questions, is:
/*
* "rc": [
* { "bin" : "binname",
* "argv" : [ "arg1", "arg2", ... ], (optional)
* "runmode" : "& OR |" (optional)
* },
* ....
* ]
(it's a comment because I happened to write it into config.c so that I'd
remember what I was implementing support for and just copypasted it from
there).
I guess it's more or less self-explanatory, except for "runmode" which
I'll get into in a while. I'm still not quite clear on how to map
"binname" with whatever was baked into the binary. For now, the first
baked binary uses the first rc array entry, the second uses the second,
etc. The hope is that "binname" would somehow easily/intuitively
correspond to the baked binary name or identifier. Also, should "argv"
contain binname (argv[0]) or not, or should it perhaps be called "args"
to better imply that it does *not* contain binname?
So, then runmode. The two runmodes are background and pipe. By
default, all programs run serialized, but with "&" you can start
execution of the next one before the previous one finishes. IOW, I hope
"&" does more or less what you'd expect it to do. So, for example, a
program which periodically prints statistics on the console can be run
this way.
Then, the pipe. It also does what you'd expect (I hope), pipes output
from the current program to the next one. It was inspired by a use case
idea someone wanted to look into. Pipes might be the most elegant way
to implement the solution for that case, though the pudding is uneaten
for now. Pipe naturally implies "&". A pipe currently pipes only
stdout, though I guess we could make it optionally pipe both if someone
really wants, though the standard idiom for that ("|&") is rather
confusing in this context.
Support for the format is in rumprun master under the key "rc_TESTING"
(so not "rc"). The rumprun tool does not generate the format at all
(and almost surely never will -- think about parsing), so you have to
write the config file by hand if you want to test things yourself.
Comments?
