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: Jeff Squyres (jsquyres_at_[hidden])
Date: 2008-08-28 09:21:06


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