On Aug 28, 2008, at 5:51 AM, Ralph Castain wrote:
The revised IOF design calls for several new cmd line options:
1. specify which procs are to receive stdin. The options that were
to be supported are: all procs, a specific proc, or no procs. The
default will be rank=0 only. All procs not included will have their
stdin tied to /dev/null - which means a debugger could not attach to
the stdin at a later time.
How about: --stdin <list>, where <list> is a comma-delimited list of
integer ranges? Such as:
--stdin 0 (same as default)
--stdin 0,1 (procs 0 and 1 get stdin)
--stdin 0-9 (proc 0 through 9 get stdin)
--stdin 0-9,23-25 (procs 0 through 9 and 23 through 25 get stdin)
--stdin all (all procs get stdin)
--stdin none (no procs get stdin)
It occurs to me that we're using this <list> kind of notation in a few
places now (aren't we?). Perhaps we should have this string-parsing
code down in opal somewhere...?
2. specify which stdxxx file descriptors you want left open on your
procs. Our defaults are to leave stdout/stderr/stddiag open on all
procs. This option would allow the user to specify that we tie any
or all of these to /dev/null
How about --stdout and --stderr, indicating which procs' stdout/stderr
you want to see? FWIW, I don't think we should provide a way to turn
off stddiag. The syntax could be just like --stdin, except the
default values would be "all".
3. tag output with [job,rank] on every line. I have currently
defined this option to be --tag-output. It is "off" by default,
though at least one user has questioned that it should be "on" by
default.
That option name is fine with me. I'd be a strong advocate of turning
it off by default, but perhaps giving an MCA param that someone can
hide in a file or the environment to always enable it if they want to.
Does anyone have suggestions as to the naming of these cmd line
options, their behavior, and/or their default settings? Any
additional requests?
Oooh... a dangerous question (additional requests). :-)
Are these options per app context, or global? It would be awesome to
be per-app-context, but I wouldn't cry too hard if they were global
(especially if it meant making the code overly complex, etc.).
--
Jeff Squyres
Cisco Systems
