Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] IOF redesign: cmd line options
From: Ralph Castain (rhc_at_[hidden])
Date: 2008-08-28 09:37:18

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
> devel_at_[hidden]