Should have known better than to send this to a list where Jeff could
see it - is there a "devel-without-Jeff" somewhere??? ;-))
On Aug 28, 2008, at 7:21 AM, Jeff Squyres wrote:
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)
Just to be clear: is this something that is necessary, or are we
providing flexibility that nobody will ever use? Frankly, I'm told
that reading stdin at all is pretty rare, at least on jobs around
here, though I don't dispute having at least the all, one, or none
capability. But is anyone really going to pick-and-choose multiple
random procs to receive stdin?
I'm asking mostly because of the complexity it adds. Certainly, it is
doable - just wondering if it is worth the effort, or something that
will never be used.
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...?
Processing it is so trivial it probably doesn't merit a dedicated code
- all you do is use opal_argv_split and run down the list.
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".
Again, will anyone ever really use this? I agree about stddiag as
orte_show_help flows over it. I haven't found any interest around here
in shutting off stdout and/or stderr - nobody can think of a reason to
do so. Doing it is trivial - my concern here is solely with the
complexity of providing such fine-grained specifications.
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.
It is an mca param already, so that's no problem - just a question
really of on/off by default.
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.).
My first reaction is that making this per app_context would create a
ton of complexity...but I'll take a gander before committing one way
or the other. Again, though, I would wonder if anyone really is going
to use this on a per app_context basis - or are we just creating
capability "because we can"?
--
Jeff Squyres
Cisco Systems
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
