2004-01-14 09:42:24 +03:00
|
|
|
/*
|
2006-02-28 15:33:42 +03:00
|
|
|
* Copyright (c) 2004-2006 The Trustees of Indiana University and Indiana
|
2005-11-05 22:57:48 +03:00
|
|
|
* University Research and Technology
|
|
|
|
* Corporation. All rights reserved.
|
2008-03-31 22:13:41 +04:00
|
|
|
* Copyright (c) 2004-2008 The University of Tennessee and The University
|
2005-11-05 22:57:48 +03:00
|
|
|
* of Tennessee Research Foundation. All rights
|
|
|
|
* reserved.
|
2006-02-28 15:33:42 +03:00
|
|
|
* Copyright (c) 2004-2006 High Performance Computing Center Stuttgart,
|
2004-11-28 23:09:25 +03:00
|
|
|
* University of Stuttgart. All rights reserved.
|
2006-02-28 15:33:42 +03:00
|
|
|
* Copyright (c) 2004-2006 The Regents of the University of California.
|
2005-03-24 15:43:37 +03:00
|
|
|
* All rights reserved.
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
* Copyright (c) 2007-2008 Cisco, Inc. All rights reserved.
|
2004-11-22 04:38:40 +03:00
|
|
|
* $COPYRIGHT$
|
|
|
|
*
|
|
|
|
* Additional copyrights may follow
|
|
|
|
*
|
2004-01-14 09:42:24 +03:00
|
|
|
* $HEADER$
|
|
|
|
*/
|
|
|
|
|
2006-02-12 04:33:29 +03:00
|
|
|
#include "opal_config.h"
|
2004-01-14 09:42:24 +03:00
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdarg.h>
|
|
|
|
#include <stdlib.h>
|
2004-10-20 05:03:09 +04:00
|
|
|
#ifdef HAVE_SYSLOG_H
|
2004-01-14 09:42:24 +03:00
|
|
|
#include <syslog.h>
|
2004-10-20 05:03:09 +04:00
|
|
|
#endif
|
2004-01-14 09:42:24 +03:00
|
|
|
#include <string.h>
|
|
|
|
#include <fcntl.h>
|
2004-10-20 05:03:09 +04:00
|
|
|
#ifdef HAVE_UNISTD_H
|
2004-01-14 09:42:24 +03:00
|
|
|
#include <unistd.h>
|
2004-10-20 05:03:09 +04:00
|
|
|
#endif
|
|
|
|
#ifdef HAVE_SYS_PARAM_H
|
2004-09-14 00:19:01 +04:00
|
|
|
#include <sys/param.h>
|
2004-10-20 05:03:09 +04:00
|
|
|
#endif
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 16:18:39 +04:00
|
|
|
#include "opal/util/opal_environ.h"
|
2005-07-04 03:31:27 +04:00
|
|
|
#include "opal/util/output.h"
|
2005-07-04 02:45:48 +04:00
|
|
|
#include "opal/threads/mutex.h"
|
2006-02-12 04:33:29 +03:00
|
|
|
#include "opal/constants.h"
|
2004-01-14 09:42:24 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Private data
|
|
|
|
*/
|
2004-01-21 02:20:59 +03:00
|
|
|
static int verbose_stream = -1;
|
2005-09-09 14:46:54 +04:00
|
|
|
static opal_output_stream_t verbose;
|
2005-09-09 16:18:39 +04:00
|
|
|
static char *output_dir = NULL;
|
|
|
|
static char *output_prefix = NULL;
|
2004-01-14 09:42:24 +03:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal data structures and helpers for the generalized output
|
|
|
|
* stream mechanism.
|
|
|
|
*/
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
typedef struct {
|
2005-09-09 13:38:43 +04:00
|
|
|
bool ldi_used;
|
|
|
|
bool ldi_enabled;
|
|
|
|
int ldi_verbose_level;
|
|
|
|
|
|
|
|
bool ldi_syslog;
|
|
|
|
int ldi_syslog_priority;
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-12-19 08:43:40 +03:00
|
|
|
#ifndef __WINDOWS__
|
2005-09-09 13:38:43 +04:00
|
|
|
char *ldi_syslog_ident;
|
|
|
|
#else
|
|
|
|
HANDLE ldi_syslog_ident;
|
2004-10-22 20:06:05 +04:00
|
|
|
#endif
|
2005-09-09 13:38:43 +04:00
|
|
|
char *ldi_prefix;
|
|
|
|
int ldi_prefix_len;
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
bool ldi_stdout;
|
|
|
|
bool ldi_stderr;
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
bool ldi_file;
|
|
|
|
bool ldi_file_want_append;
|
|
|
|
char *ldi_file_suffix;
|
|
|
|
int ldi_fd;
|
|
|
|
int ldi_file_num_lines_lost;
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
|
|
|
|
int ldi_filter_flags;
|
|
|
|
} output_desc_t;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Private functions
|
|
|
|
*/
|
|
|
|
static void construct(opal_object_t *stream);
|
|
|
|
static int do_open(int output_id, opal_output_stream_t * lds);
|
|
|
|
static int open_file(int i);
|
|
|
|
static void free_descriptor(int output_id);
|
|
|
|
static int make_string(char **no_newline_string, output_desc_t *ldi,
|
|
|
|
const char *format, va_list arglist);
|
|
|
|
static int output(int output_id, const char *format, va_list arglist);
|
|
|
|
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-07-04 03:31:27 +04:00
|
|
|
#define OPAL_OUTPUT_MAX_STREAMS 32
|
2007-04-17 07:11:30 +04:00
|
|
|
#if defined(__WINDOWS__) || defined(HAVE_SYSLOG)
|
|
|
|
#define USE_SYSLOG 1
|
|
|
|
#else
|
|
|
|
#define USE_SYSLOG 0
|
|
|
|
#endif
|
2004-01-14 09:42:24 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Local state
|
|
|
|
*/
|
|
|
|
static bool initialized = false;
|
2005-07-04 03:31:27 +04:00
|
|
|
static output_desc_t info[OPAL_OUTPUT_MAX_STREAMS];
|
2004-01-14 09:42:24 +03:00
|
|
|
static char *temp_str = 0;
|
2004-10-26 14:56:08 +04:00
|
|
|
static size_t temp_str_len = 0;
|
2005-07-04 02:45:48 +04:00
|
|
|
static opal_mutex_t mutex;
|
2004-10-14 22:01:18 +04:00
|
|
|
static bool syslog_opened = false;
|
2004-01-14 09:42:24 +03:00
|
|
|
|
|
|
|
|
2005-09-09 14:46:54 +04:00
|
|
|
OBJ_CLASS_INSTANCE(opal_output_stream_t, opal_object_t, construct, NULL);
|
|
|
|
|
2004-03-27 05:48:04 +03:00
|
|
|
/*
|
|
|
|
* Setup the output stream infrastructure
|
2004-01-14 09:42:24 +03:00
|
|
|
*/
|
2005-07-04 03:31:27 +04:00
|
|
|
bool opal_output_init(void)
|
2004-01-14 09:42:24 +03:00
|
|
|
{
|
2005-09-09 13:38:43 +04:00
|
|
|
int i;
|
2005-09-27 23:27:26 +04:00
|
|
|
char hostname[32];
|
2005-08-25 00:19:36 +04:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
if (initialized) {
|
2006-08-23 04:29:35 +04:00
|
|
|
return true;
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 14:46:54 +04:00
|
|
|
OBJ_CONSTRUCT(&verbose, opal_output_stream_t);
|
2006-08-23 04:29:35 +04:00
|
|
|
#if defined(__WINDOWS__)
|
|
|
|
{
|
|
|
|
WSADATA wsaData;
|
|
|
|
WSAStartup( MAKEWORD(2,2), &wsaData );
|
|
|
|
}
|
|
|
|
#endif /* defined(__WINDOWS__) */
|
2005-09-27 23:27:26 +04:00
|
|
|
gethostname(hostname, sizeof(hostname));
|
2005-09-09 14:46:54 +04:00
|
|
|
verbose.lds_want_stderr = true;
|
2005-09-27 23:27:26 +04:00
|
|
|
asprintf(&verbose.lds_prefix, "[%s:%05d] ", hostname, getpid());
|
2005-09-09 14:46:54 +04:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
for (i = 0; i < OPAL_OUTPUT_MAX_STREAMS; ++i) {
|
2006-08-23 04:29:35 +04:00
|
|
|
info[i].ldi_used = false;
|
|
|
|
info[i].ldi_enabled = false;
|
|
|
|
|
|
|
|
info[i].ldi_syslog = false;
|
|
|
|
info[i].ldi_file = false;
|
|
|
|
info[i].ldi_file_suffix = NULL;
|
|
|
|
info[i].ldi_file_want_append = false;
|
|
|
|
info[i].ldi_fd = -1;
|
|
|
|
info[i].ldi_file_num_lines_lost = 0;
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
info[i].ldi_filter_flags =
|
|
|
|
OPAL_OUTPUT_FILTER_STDOUT | OPAL_OUTPUT_FILTER_STDERR;
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* Initialize the mutex that protects the output */
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
OBJ_CONSTRUCT(&mutex, opal_mutex_t);
|
|
|
|
initialized = true;
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 16:18:39 +04:00
|
|
|
/* Set some defaults */
|
|
|
|
|
2005-09-09 16:37:39 +04:00
|
|
|
asprintf(&output_prefix, "output-pid%d-", getpid());
|
2008-03-31 22:13:41 +04:00
|
|
|
output_dir = strdup(opal_tmp_directory());
|
2005-09-09 16:18:39 +04:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* Open the default verbose stream */
|
|
|
|
verbose_stream = opal_output_open(&verbose);
|
|
|
|
return true;
|
2004-01-14 09:42:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-03-27 05:48:04 +03:00
|
|
|
/*
|
|
|
|
* Open a stream
|
2004-01-14 09:42:24 +03:00
|
|
|
*/
|
2005-09-09 13:38:43 +04:00
|
|
|
int opal_output_open(opal_output_stream_t * lds)
|
2004-01-14 09:42:24 +03:00
|
|
|
{
|
2005-09-09 13:38:43 +04:00
|
|
|
return do_open(-1, lds);
|
2004-01-16 04:33:43 +03:00
|
|
|
}
|
2004-01-14 09:42:24 +03:00
|
|
|
|
|
|
|
|
2004-03-27 05:48:04 +03:00
|
|
|
/*
|
|
|
|
* Reset the parameters on a stream
|
2004-01-16 04:33:43 +03:00
|
|
|
*/
|
2005-09-09 13:38:43 +04:00
|
|
|
int opal_output_reopen(int output_id, opal_output_stream_t * lds)
|
2004-01-16 04:33:43 +03:00
|
|
|
{
|
2005-09-09 13:38:43 +04:00
|
|
|
return do_open(output_id, lds);
|
2004-01-14 09:42:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-03-27 05:48:04 +03:00
|
|
|
/*
|
2008-03-31 22:13:41 +04:00
|
|
|
* Enable and disable output streams
|
2004-01-14 09:42:24 +03:00
|
|
|
*/
|
2005-07-04 03:31:27 +04:00
|
|
|
bool opal_output_switch(int output_id, bool enable)
|
2004-01-14 09:42:24 +03:00
|
|
|
{
|
2005-09-09 13:38:43 +04:00
|
|
|
bool ret = false;
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* Setup */
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
if (!initialized) {
|
2006-08-23 04:29:35 +04:00
|
|
|
opal_output_init();
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
if (output_id >= 0 && output_id < OPAL_OUTPUT_MAX_STREAMS) {
|
2006-08-23 04:29:35 +04:00
|
|
|
ret = info[output_id].ldi_enabled;
|
|
|
|
info[output_id].ldi_enabled = enable;
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
return ret;
|
2004-01-14 09:42:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-03-27 05:48:04 +03:00
|
|
|
/*
|
|
|
|
* Reopen all the streams; used during checkpoint/restart.
|
2004-01-14 09:42:24 +03:00
|
|
|
*/
|
2005-07-04 03:31:27 +04:00
|
|
|
void opal_output_reopen_all(void)
|
2004-01-14 09:42:24 +03:00
|
|
|
{
|
2005-09-09 13:38:43 +04:00
|
|
|
int i;
|
|
|
|
opal_output_stream_t lds;
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
for (i = 0; i < OPAL_OUTPUT_MAX_STREAMS; ++i) {
|
2004-06-29 04:02:25 +04:00
|
|
|
|
2006-08-23 04:29:35 +04:00
|
|
|
/* scan till we find ldi_used == 0, which is the end-marker */
|
2005-09-09 13:38:43 +04:00
|
|
|
|
2006-08-23 04:29:35 +04:00
|
|
|
if (!info[i].ldi_used) {
|
|
|
|
break;
|
|
|
|
}
|
2005-09-09 13:38:43 +04:00
|
|
|
|
2006-08-23 04:29:35 +04:00
|
|
|
/*
|
|
|
|
* set this to zero to ensure that opal_output_open will
|
|
|
|
* return this same index as the output stream id
|
|
|
|
*/
|
|
|
|
info[i].ldi_used = false;
|
|
|
|
|
2007-04-17 07:11:30 +04:00
|
|
|
#if USE_SYSLOG
|
2006-08-23 04:29:35 +04:00
|
|
|
lds.lds_want_syslog = info[i].ldi_syslog;
|
|
|
|
lds.lds_syslog_priority = info[i].ldi_syslog_priority;
|
|
|
|
lds.lds_syslog_ident = info[i].ldi_syslog_ident;
|
2007-04-17 07:11:30 +04:00
|
|
|
#else
|
|
|
|
lds.lds_want_syslog = false;
|
|
|
|
#endif
|
2006-08-23 04:29:35 +04:00
|
|
|
lds.lds_prefix = info[i].ldi_prefix;
|
|
|
|
lds.lds_want_stdout = info[i].ldi_stdout;
|
|
|
|
lds.lds_want_stderr = info[i].ldi_stderr;
|
|
|
|
lds.lds_want_file = (-1 == info[i].ldi_fd) ? false : true;
|
|
|
|
/* open all streams in append mode */
|
|
|
|
lds.lds_want_file_append = true;
|
|
|
|
lds.lds_file_suffix = info[i].ldi_file_suffix;
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
lds.lds_filter_flags = info[i].ldi_filter_flags;
|
2006-08-23 04:29:35 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* call opal_output_open to open the stream. The return value
|
|
|
|
* is guaranteed to be i. So we can ignore it.
|
|
|
|
*/
|
|
|
|
opal_output_open(&lds);
|
2004-06-29 04:02:25 +04:00
|
|
|
}
|
2004-01-14 09:42:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-03-27 05:48:04 +03:00
|
|
|
/*
|
|
|
|
* Close a stream
|
2004-01-14 09:42:24 +03:00
|
|
|
*/
|
2005-07-04 03:31:27 +04:00
|
|
|
void opal_output_close(int output_id)
|
2004-01-14 09:42:24 +03:00
|
|
|
{
|
2005-09-09 13:38:43 +04:00
|
|
|
int i;
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* Setup */
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
if (!initialized) {
|
2005-09-09 14:46:54 +04:00
|
|
|
return;
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* If it's valid, used, enabled, and has an open file descriptor,
|
|
|
|
* free the resources associated with the descriptor */
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-27 20:43:48 +04:00
|
|
|
OPAL_THREAD_LOCK(&mutex);
|
2005-09-09 13:38:43 +04:00
|
|
|
if (output_id >= 0 && output_id < OPAL_OUTPUT_MAX_STREAMS &&
|
2006-08-23 04:29:35 +04:00
|
|
|
info[output_id].ldi_used && info[output_id].ldi_enabled) {
|
|
|
|
free_descriptor(output_id);
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-27 20:43:48 +04:00
|
|
|
/* If no one has the syslog open, we should close it */
|
|
|
|
|
|
|
|
for (i = 0; i < OPAL_OUTPUT_MAX_STREAMS; ++i) {
|
|
|
|
if (info[i].ldi_used && info[i].ldi_syslog) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2005-09-09 13:38:43 +04:00
|
|
|
|
2007-04-17 07:11:30 +04:00
|
|
|
#if defined(HAVE_SYSLOG)
|
2005-09-27 20:43:48 +04:00
|
|
|
if (i >= OPAL_OUTPUT_MAX_STREAMS && syslog_opened) {
|
|
|
|
closelog();
|
|
|
|
}
|
2007-04-17 07:11:30 +04:00
|
|
|
#elif defined(__WINDOWS__)
|
2007-06-21 11:53:47 +04:00
|
|
|
if(info[output_id].ldi_syslog_ident != NULL) {
|
2007-06-21 11:49:11 +04:00
|
|
|
DeregisterEventSource(info[output_id].ldi_syslog_ident);
|
2007-06-21 11:53:47 +04:00
|
|
|
}
|
2004-10-22 20:06:05 +04:00
|
|
|
#endif
|
2005-09-27 20:43:48 +04:00
|
|
|
}
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* Somewhat of a hack to free up the temp_str */
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
if (NULL != temp_str) {
|
2006-08-23 04:29:35 +04:00
|
|
|
free(temp_str);
|
|
|
|
temp_str = NULL;
|
|
|
|
temp_str_len = 0;
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
|
|
|
OPAL_THREAD_UNLOCK(&mutex);
|
2004-01-14 09:42:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-03-27 05:48:04 +03:00
|
|
|
/*
|
|
|
|
* Main function to send output to a stream
|
2004-01-14 09:42:24 +03:00
|
|
|
*/
|
2005-07-04 03:31:27 +04:00
|
|
|
void opal_output(int output_id, const char *format, ...)
|
2004-01-14 09:42:24 +03:00
|
|
|
{
|
2005-09-27 20:43:48 +04:00
|
|
|
if (output_id >= 0 && output_id < OPAL_OUTPUT_MAX_STREAMS) {
|
|
|
|
va_list arglist;
|
|
|
|
va_start(arglist, format);
|
|
|
|
output(output_id, format, arglist);
|
|
|
|
va_end(arglist);
|
|
|
|
}
|
2004-01-14 09:42:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-03-27 05:48:04 +03:00
|
|
|
/*
|
|
|
|
* Send a message to a stream if the verbose level is high enough
|
2004-01-14 09:42:24 +03:00
|
|
|
*/
|
2005-07-04 03:31:27 +04:00
|
|
|
void opal_output_verbose(int level, int output_id, const char *format, ...)
|
2004-01-14 09:42:24 +03:00
|
|
|
{
|
2005-09-27 20:43:48 +04:00
|
|
|
if (output_id >= 0 && output_id < OPAL_OUTPUT_MAX_STREAMS &&
|
|
|
|
info[output_id].ldi_verbose_level >= level) {
|
2006-08-23 04:29:35 +04:00
|
|
|
va_list arglist;
|
|
|
|
va_start(arglist, format);
|
|
|
|
output(output_id, format, arglist);
|
|
|
|
va_end(arglist);
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
2004-01-14 09:42:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
/*
|
|
|
|
* Send a message to a stream if the verbose level is high enough
|
|
|
|
*/
|
|
|
|
void opal_output_vverbose(int level, int output_id, const char *format,
|
|
|
|
va_list arglist)
|
|
|
|
{
|
|
|
|
if (output_id >= 0 && output_id < OPAL_OUTPUT_MAX_STREAMS &&
|
|
|
|
info[output_id].ldi_verbose_level >= level) {
|
|
|
|
output(output_id, format, arglist);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Send a message to a string if the verbose level is high enough
|
|
|
|
*/
|
|
|
|
char *opal_output_string(int level, int output_id, const char *format, ...)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
char *ret = NULL;
|
|
|
|
|
|
|
|
if (output_id >= 0 && output_id < OPAL_OUTPUT_MAX_STREAMS &&
|
|
|
|
info[output_id].ldi_verbose_level >= level) {
|
|
|
|
va_list arglist;
|
|
|
|
va_start(arglist, format);
|
|
|
|
rc = make_string(&ret, &info[output_id], format, arglist);
|
|
|
|
va_end(arglist);
|
|
|
|
if (OPAL_SUCCESS != rc) {
|
|
|
|
ret = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Send a message to a string if the verbose level is high enough
|
|
|
|
*/
|
|
|
|
char *opal_output_vstring(int level, int output_id, const char *format,
|
|
|
|
va_list arglist)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
char *ret = NULL;
|
|
|
|
|
|
|
|
if (output_id >= 0 && output_id < OPAL_OUTPUT_MAX_STREAMS &&
|
|
|
|
info[output_id].ldi_verbose_level >= level) {
|
|
|
|
rc = make_string(&ret, &info[output_id], format, arglist);
|
|
|
|
if (OPAL_SUCCESS != rc) {
|
|
|
|
ret = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-03-27 05:48:04 +03:00
|
|
|
/*
|
|
|
|
* Set the verbosity level of a stream
|
2004-01-14 09:42:24 +03:00
|
|
|
*/
|
2005-07-04 03:31:27 +04:00
|
|
|
void opal_output_set_verbosity(int output_id, int level)
|
2004-01-14 09:42:24 +03:00
|
|
|
{
|
2005-09-27 20:43:48 +04:00
|
|
|
if (output_id >= 0 && output_id < OPAL_OUTPUT_MAX_STREAMS) {
|
|
|
|
info[output_id].ldi_verbose_level = level;
|
|
|
|
}
|
2004-01-14 09:42:24 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-09-09 16:18:39 +04:00
|
|
|
/*
|
|
|
|
* Control where output flies will go
|
|
|
|
*/
|
|
|
|
void opal_output_set_output_file_info(const char *dir,
|
|
|
|
const char *prefix,
|
|
|
|
char **olddir,
|
|
|
|
char **oldprefix)
|
|
|
|
{
|
|
|
|
if (NULL != olddir) {
|
|
|
|
*olddir = strdup(output_dir);
|
|
|
|
}
|
|
|
|
if (NULL != oldprefix) {
|
|
|
|
*oldprefix = strdup(output_prefix);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (NULL != dir) {
|
|
|
|
free(output_dir);
|
|
|
|
output_dir = strdup(dir);
|
|
|
|
}
|
|
|
|
if (NULL != prefix) {
|
|
|
|
free(output_prefix);
|
|
|
|
output_prefix = strdup(prefix);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-03-27 05:48:04 +03:00
|
|
|
/*
|
|
|
|
* Shut down the output stream system
|
2004-01-14 09:42:24 +03:00
|
|
|
*/
|
2005-07-04 03:31:27 +04:00
|
|
|
void opal_output_finalize(void)
|
2004-01-14 09:42:24 +03:00
|
|
|
{
|
2005-09-09 13:38:43 +04:00
|
|
|
if (initialized) {
|
2006-02-28 15:33:42 +03:00
|
|
|
if (verbose_stream != -1) {
|
|
|
|
opal_output_close(verbose_stream);
|
|
|
|
}
|
|
|
|
verbose_stream = -1;
|
|
|
|
|
|
|
|
free (output_prefix);
|
|
|
|
free (output_dir);
|
|
|
|
OBJ_DESTRUCT(&verbose);
|
|
|
|
OBJ_DESTRUCT(&mutex);
|
2004-06-29 04:02:25 +04:00
|
|
|
}
|
2006-08-23 04:29:35 +04:00
|
|
|
#if defined(__WINDOWS__)
|
|
|
|
WSACleanup();
|
|
|
|
#endif /* defined(__WINDOWS__) */
|
2004-01-14 09:42:24 +03:00
|
|
|
}
|
|
|
|
|
2004-03-27 05:48:04 +03:00
|
|
|
/************************************************************************/
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2005-09-09 14:46:54 +04:00
|
|
|
/*
|
|
|
|
* Constructor
|
|
|
|
*/
|
|
|
|
static void construct(opal_object_t *obj)
|
|
|
|
{
|
|
|
|
opal_output_stream_t *stream = (opal_output_stream_t*) obj;
|
|
|
|
|
|
|
|
stream->lds_verbose_level = 0;
|
|
|
|
stream->lds_syslog_priority = 0;
|
|
|
|
stream->lds_syslog_ident = NULL;
|
|
|
|
stream->lds_prefix = NULL;
|
2006-08-23 04:29:35 +04:00
|
|
|
stream->lds_is_debugging = false;
|
|
|
|
stream->lds_want_syslog = false;
|
2005-09-09 14:46:54 +04:00
|
|
|
stream->lds_want_stdout = false;
|
2006-08-23 04:29:35 +04:00
|
|
|
stream->lds_want_stderr = false;
|
2005-09-09 14:46:54 +04:00
|
|
|
stream->lds_want_file = false;
|
|
|
|
stream->lds_want_file_append = false;
|
|
|
|
stream->lds_file_suffix = NULL;
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
stream->lds_filter_flags =
|
|
|
|
OPAL_OUTPUT_FILTER_STDOUT | OPAL_OUTPUT_FILTER_STDERR;
|
2005-09-09 14:46:54 +04:00
|
|
|
}
|
|
|
|
|
2004-01-16 04:33:43 +03:00
|
|
|
/*
|
|
|
|
* Back-end of open() and reopen(). Necessary to have it as a
|
|
|
|
* back-end function so that we can do the thread locking properly
|
|
|
|
* (especially upon reopen).
|
|
|
|
*/
|
2005-09-09 13:38:43 +04:00
|
|
|
static int do_open(int output_id, opal_output_stream_t * lds)
|
2004-09-14 00:19:01 +04:00
|
|
|
{
|
2005-09-09 13:38:43 +04:00
|
|
|
int i;
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* Setup */
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
if (!initialized) {
|
2006-08-23 04:29:35 +04:00
|
|
|
opal_output_init();
|
2004-06-29 04:02:25 +04:00
|
|
|
}
|
2005-09-09 13:38:43 +04:00
|
|
|
|
|
|
|
/* If output_id == -1, find an available stream, or return
|
2006-02-12 04:33:29 +03:00
|
|
|
* OPAL_ERROR */
|
2005-09-09 13:38:43 +04:00
|
|
|
|
|
|
|
if (-1 == output_id) {
|
2006-08-23 04:29:35 +04:00
|
|
|
OPAL_THREAD_LOCK(&mutex);
|
|
|
|
for (i = 0; i < OPAL_OUTPUT_MAX_STREAMS; ++i) {
|
|
|
|
if (!info[i].ldi_used) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (i >= OPAL_OUTPUT_MAX_STREAMS) {
|
|
|
|
OPAL_THREAD_UNLOCK(&mutex);
|
|
|
|
return OPAL_ERR_OUT_OF_RESOURCE;
|
|
|
|
}
|
2004-01-16 04:33:43 +03:00
|
|
|
}
|
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* Otherwise, we're reopening, so we need to free all previous
|
|
|
|
* resources, close files, etc. */
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
else {
|
2006-08-23 04:29:35 +04:00
|
|
|
free_descriptor(output_id);
|
|
|
|
i = output_id;
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* Special case: if we got NULL for lds, then just use the default
|
|
|
|
* verbose */
|
2004-05-19 23:52:24 +04:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
if (NULL == lds) {
|
2006-08-23 04:29:35 +04:00
|
|
|
lds = &verbose;
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
2004-05-19 23:52:24 +04:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* Got a stream -- now initialize it and open relevant outputs */
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
info[i].ldi_used = true;
|
|
|
|
if (-1 == output_id) {
|
2006-08-23 04:29:35 +04:00
|
|
|
OPAL_THREAD_UNLOCK(&mutex);
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
|
|
|
info[i].ldi_enabled = lds->lds_is_debugging ?
|
2006-08-23 04:29:35 +04:00
|
|
|
(bool) OMPI_ENABLE_DEBUG : true;
|
2005-09-09 13:38:43 +04:00
|
|
|
info[i].ldi_verbose_level = lds->lds_verbose_level;
|
|
|
|
|
2007-04-17 07:11:30 +04:00
|
|
|
#if USE_SYSLOG
|
2005-09-09 13:38:43 +04:00
|
|
|
info[i].ldi_syslog = lds->lds_want_syslog;
|
|
|
|
if (lds->lds_want_syslog) {
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2007-04-17 07:11:30 +04:00
|
|
|
#if defined(HAVE_SYSLOG)
|
2006-08-23 04:29:35 +04:00
|
|
|
if (NULL != lds->lds_syslog_ident) {
|
|
|
|
info[i].ldi_syslog_ident = strdup(lds->lds_syslog_ident);
|
|
|
|
openlog(lds->lds_syslog_ident, LOG_PID, LOG_USER);
|
|
|
|
} else {
|
|
|
|
info[i].ldi_syslog_ident = NULL;
|
|
|
|
openlog("opal", LOG_PID, LOG_USER);
|
|
|
|
}
|
2007-04-17 07:11:30 +04:00
|
|
|
#elif defined(__WINDOWS__)
|
2006-08-23 04:29:35 +04:00
|
|
|
if (NULL == (info[i].ldi_syslog_ident =
|
|
|
|
RegisterEventSource(NULL, TEXT("opal: ")))) {
|
|
|
|
/* handle the error */
|
|
|
|
return OPAL_ERROR;
|
|
|
|
}
|
2004-10-22 20:06:05 +04:00
|
|
|
#endif
|
2005-09-09 13:38:43 +04:00
|
|
|
|
2006-08-23 04:29:35 +04:00
|
|
|
syslog_opened = true;
|
|
|
|
info[i].ldi_syslog_priority = lds->lds_syslog_priority;
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
2007-04-17 07:11:30 +04:00
|
|
|
#else
|
2007-12-06 14:36:44 +03:00
|
|
|
info[i].ldi_syslog = false;
|
2007-04-17 07:11:30 +04:00
|
|
|
#endif
|
2005-09-09 13:38:43 +04:00
|
|
|
|
|
|
|
if (NULL != lds->lds_prefix) {
|
2006-08-23 04:29:35 +04:00
|
|
|
info[i].ldi_prefix = strdup(lds->lds_prefix);
|
|
|
|
info[i].ldi_prefix_len = (int)strlen(lds->lds_prefix);
|
2005-09-09 13:38:43 +04:00
|
|
|
} else {
|
2006-08-23 04:29:35 +04:00
|
|
|
info[i].ldi_prefix = NULL;
|
|
|
|
info[i].ldi_prefix_len = 0;
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
info[i].ldi_stdout = lds->lds_want_stdout;
|
|
|
|
info[i].ldi_stderr = lds->lds_want_stderr;
|
|
|
|
|
|
|
|
info[i].ldi_fd = -1;
|
|
|
|
info[i].ldi_file = lds->lds_want_file;
|
|
|
|
info[i].ldi_file_suffix = (NULL == lds->lds_file_suffix) ? NULL :
|
2006-08-23 04:29:35 +04:00
|
|
|
strdup(lds->lds_file_suffix);
|
2005-09-09 13:38:43 +04:00
|
|
|
info[i].ldi_file_want_append = lds->lds_want_file_append;
|
|
|
|
info[i].ldi_file_num_lines_lost = 0;
|
|
|
|
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
info[i].ldi_filter_flags = lds->lds_filter_flags;
|
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* Don't open a file in the session directory now -- do that lazily
|
|
|
|
* so that if there's no output, we don't have an empty file */
|
|
|
|
|
|
|
|
return i;
|
2004-09-14 00:19:01 +04:00
|
|
|
}
|
2004-01-16 04:33:43 +03:00
|
|
|
|
|
|
|
|
2004-09-14 00:19:01 +04:00
|
|
|
static int open_file(int i)
|
|
|
|
{
|
|
|
|
int flags;
|
2005-09-09 16:18:39 +04:00
|
|
|
char *filename;
|
2004-09-14 00:19:01 +04:00
|
|
|
|
|
|
|
/* Setup the filename and open flags */
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2005-09-09 16:18:39 +04:00
|
|
|
if (NULL != output_dir) {
|
2007-09-14 06:08:37 +04:00
|
|
|
filename = (char *) malloc(OMPI_PATH_MAX);
|
|
|
|
if (NULL == filename) {
|
|
|
|
return OPAL_ERR_OUT_OF_RESOURCE;
|
|
|
|
}
|
|
|
|
strncpy(filename, output_dir, OMPI_PATH_MAX);
|
|
|
|
strcat(filename, "/");
|
2005-09-09 16:18:39 +04:00
|
|
|
if (NULL != output_prefix) {
|
|
|
|
strcat(filename, output_prefix);
|
|
|
|
}
|
2007-09-14 06:08:37 +04:00
|
|
|
if (info[i].ldi_file_suffix != NULL) {
|
|
|
|
strcat(filename, info[i].ldi_file_suffix);
|
|
|
|
} else {
|
|
|
|
info[i].ldi_file_suffix = NULL;
|
|
|
|
strcat(filename, "output.txt");
|
|
|
|
}
|
|
|
|
flags = O_CREAT | O_RDWR;
|
|
|
|
if (!info[i].ldi_file_want_append) {
|
|
|
|
flags |= O_TRUNC;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Actually open the file */
|
|
|
|
info[i].ldi_fd = open(filename, flags, 0644);
|
|
|
|
if (-1 == info[i].ldi_fd) {
|
|
|
|
info[i].ldi_used = false;
|
|
|
|
free(filename);
|
|
|
|
return OPAL_ERR_IN_ERRNO;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Make the file be close-on-exec to prevent child inheritance
|
|
|
|
* problems */
|
2005-09-09 13:38:43 +04:00
|
|
|
|
2005-12-19 08:43:40 +03:00
|
|
|
#ifndef __WINDOWS__
|
2007-09-14 06:08:37 +04:00
|
|
|
/* TODO: Need to find out the equivalent in windows */
|
|
|
|
fcntl(info[i].ldi_fd, F_SETFD, 1);
|
2004-10-22 20:06:05 +04:00
|
|
|
#endif
|
2005-09-09 13:38:43 +04:00
|
|
|
|
2007-09-14 06:08:37 +04:00
|
|
|
free(filename);
|
2004-01-16 04:33:43 +03:00
|
|
|
}
|
|
|
|
|
2004-09-14 00:19:01 +04:00
|
|
|
/* Return successfully even if the session dir did not exist yet;
|
2005-09-09 13:38:43 +04:00
|
|
|
* we'll try opening it later */
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2006-02-12 04:33:29 +03:00
|
|
|
return OPAL_SUCCESS;
|
2004-01-16 04:33:43 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Free all the resources associated with a descriptor.
|
|
|
|
*/
|
|
|
|
static void free_descriptor(int output_id)
|
|
|
|
{
|
2005-09-09 13:38:43 +04:00
|
|
|
output_desc_t *ldi;
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
if (output_id >= 0 && output_id < OPAL_OUTPUT_MAX_STREAMS &&
|
|
|
|
info[output_id].ldi_used && info[output_id].ldi_enabled) {
|
|
|
|
ldi = &info[output_id];
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
if (-1 != ldi->ldi_fd) {
|
|
|
|
close(ldi->ldi_fd);
|
|
|
|
}
|
|
|
|
ldi->ldi_used = false;
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* If we strduped a prefix, suffix, or syslog ident, free it */
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
if (NULL != ldi->ldi_prefix) {
|
|
|
|
free(ldi->ldi_prefix);
|
|
|
|
}
|
|
|
|
ldi->ldi_prefix = NULL;
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
if (NULL != ldi->ldi_file_suffix) {
|
|
|
|
free(ldi->ldi_file_suffix);
|
|
|
|
}
|
|
|
|
ldi->ldi_file_suffix = NULL;
|
2004-01-16 04:33:43 +03:00
|
|
|
|
2005-12-19 08:43:40 +03:00
|
|
|
#ifndef __WINDOWS__
|
2005-09-09 13:38:43 +04:00
|
|
|
if (NULL != ldi->ldi_syslog_ident) {
|
|
|
|
free(ldi->ldi_syslog_ident);
|
|
|
|
}
|
|
|
|
ldi->ldi_syslog_ident = NULL;
|
2004-10-22 20:06:05 +04:00
|
|
|
#endif
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
2004-01-16 04:33:43 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
static int make_string(char **no_newline_string, output_desc_t *ldi,
|
|
|
|
const char *format, va_list arglist)
|
|
|
|
{
|
|
|
|
size_t len, total_len;
|
|
|
|
bool want_newline = false;
|
|
|
|
|
|
|
|
/* Make the formatted string */
|
|
|
|
|
|
|
|
vasprintf(no_newline_string, format, arglist);
|
|
|
|
total_len = len = strlen(*no_newline_string);
|
|
|
|
if ('\n' != (*no_newline_string)[len - 1]) {
|
|
|
|
want_newline = true;
|
|
|
|
++total_len;
|
|
|
|
}
|
|
|
|
if (NULL != ldi->ldi_prefix) {
|
|
|
|
total_len += strlen(ldi->ldi_prefix);
|
|
|
|
}
|
|
|
|
if (temp_str_len < total_len + want_newline) {
|
|
|
|
if (NULL != temp_str) {
|
|
|
|
free(temp_str);
|
|
|
|
}
|
|
|
|
temp_str = (char *) malloc(total_len * 2);
|
|
|
|
if (NULL == temp_str) {
|
|
|
|
return OPAL_ERR_OUT_OF_RESOURCE;
|
|
|
|
}
|
|
|
|
temp_str_len = total_len * 2;
|
|
|
|
}
|
|
|
|
if (NULL != ldi->ldi_prefix) {
|
|
|
|
if (want_newline) {
|
|
|
|
snprintf(temp_str, temp_str_len, "%s%s\n", ldi->ldi_prefix,
|
|
|
|
*no_newline_string);
|
|
|
|
} else {
|
|
|
|
snprintf(temp_str, temp_str_len, "%s%s", ldi->ldi_prefix,
|
|
|
|
*no_newline_string);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (want_newline) {
|
|
|
|
snprintf(temp_str, temp_str_len, "%s\n", *no_newline_string);
|
|
|
|
} else {
|
|
|
|
snprintf(temp_str, temp_str_len, "%s", *no_newline_string);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return OPAL_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2004-01-14 09:42:24 +03:00
|
|
|
/*
|
|
|
|
* Do the actual output. Take a va_list so that we can be called from
|
|
|
|
* multiple different places, even functions that took "..." as input
|
|
|
|
* arguments.
|
|
|
|
*/
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
static int output(int output_id, const char *format, va_list arglist)
|
2004-01-14 09:42:24 +03:00
|
|
|
{
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
int rc = OPAL_SUCCESS;
|
|
|
|
char *str, *out = NULL;
|
2005-09-09 13:38:43 +04:00
|
|
|
output_desc_t *ldi;
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* Setup */
|
2004-01-14 09:42:24 +03:00
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
if (!initialized) {
|
2007-08-04 04:44:23 +04:00
|
|
|
opal_output_init();
|
2004-01-14 09:42:24 +03:00
|
|
|
}
|
|
|
|
|
2005-09-09 13:38:43 +04:00
|
|
|
/* If it's valid, used, and enabled, output */
|
|
|
|
|
|
|
|
if (output_id >= 0 && output_id < OPAL_OUTPUT_MAX_STREAMS &&
|
2007-08-04 04:44:23 +04:00
|
|
|
info[output_id].ldi_used && info[output_id].ldi_enabled) {
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
OPAL_THREAD_LOCK(&mutex);
|
2007-08-04 04:44:23 +04:00
|
|
|
ldi = &info[output_id];
|
2005-09-09 13:38:43 +04:00
|
|
|
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
/* Make the strings */
|
|
|
|
if (OPAL_SUCCESS != (rc = make_string(&str, ldi, format, arglist))) {
|
|
|
|
OPAL_THREAD_UNLOCK(&mutex);
|
|
|
|
return rc;
|
2007-08-04 04:44:23 +04:00
|
|
|
}
|
2005-09-09 13:38:43 +04:00
|
|
|
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
/* Syslog output -- does not use the newline-appended string */
|
2007-04-17 07:11:30 +04:00
|
|
|
#if defined(HAVE_SYSLOG)
|
2007-08-04 04:44:23 +04:00
|
|
|
if (ldi->ldi_syslog) {
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
char *out = str;
|
|
|
|
if (ldi->ldi_filter_flags & OPAL_OUTPUT_FILTER_SYSLOG) {
|
|
|
|
#if 0
|
|
|
|
/* JMS call the filter, perhaps like this */
|
|
|
|
out = filter(str);
|
|
|
|
if (NULL == out) {
|
|
|
|
out = str;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
syslog(ldi->ldi_syslog_priority, "%s", str);
|
|
|
|
if (out != str) {
|
|
|
|
free(out);
|
|
|
|
}
|
2007-08-04 04:44:23 +04:00
|
|
|
}
|
2004-10-22 20:06:05 +04:00
|
|
|
#endif
|
2005-09-09 13:38:43 +04:00
|
|
|
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
/* All others (stdout, stderr, file) use temp_str, potentially
|
|
|
|
with a newline appended */
|
|
|
|
|
|
|
|
out = temp_str;
|
|
|
|
if ((ldi->ldi_stdout &&
|
|
|
|
ldi->ldi_filter_flags & OPAL_OUTPUT_FILTER_STDOUT) ||
|
|
|
|
(ldi->ldi_stderr &&
|
|
|
|
ldi->ldi_filter_flags & OPAL_OUTPUT_FILTER_STDERR) ||
|
|
|
|
(ldi->ldi_file &&
|
|
|
|
ldi->ldi_filter_flags & OPAL_OUTPUT_FILTER_FILE)) {
|
|
|
|
#if 0
|
|
|
|
/* JMS call the filter, perhaps like this */
|
|
|
|
out = filter(temp_str);
|
|
|
|
if (NULL == out) {
|
|
|
|
out = temp_str;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2007-08-04 04:44:23 +04:00
|
|
|
/* stdout output */
|
|
|
|
if (ldi->ldi_stdout) {
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
write(fileno(stdout), out, (int)strlen(out));
|
2006-10-11 22:40:21 +04:00
|
|
|
fflush(stdout);
|
2007-08-04 04:44:23 +04:00
|
|
|
}
|
2005-09-09 13:38:43 +04:00
|
|
|
|
2007-08-04 04:44:23 +04:00
|
|
|
/* stderr output */
|
|
|
|
if (ldi->ldi_stderr) {
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
write(fileno(stderr), out, (int)strlen(out));
|
2006-10-11 22:40:21 +04:00
|
|
|
fflush(stderr);
|
2005-09-09 13:38:43 +04:00
|
|
|
}
|
|
|
|
|
2007-08-04 04:44:23 +04:00
|
|
|
/* File output -- first check to see if the file opening was
|
|
|
|
* delayed. If so, try to open it. If we failed to open it,
|
|
|
|
* then just discard (there are big warnings in the
|
|
|
|
* opal_output.h docs about this!). */
|
|
|
|
|
|
|
|
if (ldi->ldi_file) {
|
|
|
|
if (ldi->ldi_fd == -1) {
|
|
|
|
if (OPAL_SUCCESS != open_file(output_id)) {
|
|
|
|
++ldi->ldi_file_num_lines_lost;
|
|
|
|
} else if (ldi->ldi_file_num_lines_lost > 0) {
|
|
|
|
char buffer[BUFSIZ];
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
char *out = buffer;
|
2007-08-04 04:44:23 +04:00
|
|
|
memset(buffer, 0, BUFSIZ);
|
|
|
|
snprintf(buffer, BUFSIZ - 1,
|
|
|
|
"[WARNING: %d lines lost because the Open MPI process session directory did\n not exist when opal_output() was invoked]\n",
|
|
|
|
ldi->ldi_file_num_lines_lost);
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
if (ldi->ldi_filter_flags & OPAL_OUTPUT_FILTER_FILE) {
|
|
|
|
#if 0
|
|
|
|
/* JMS call the filter */
|
|
|
|
out = filter(buffer);
|
|
|
|
if (NULL == out) {
|
|
|
|
out = buffer;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
2007-08-04 04:44:23 +04:00
|
|
|
write(ldi->ldi_fd, buffer, (int)strlen(buffer));
|
|
|
|
ldi->ldi_file_num_lines_lost = 0;
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
if (out != buffer) {
|
|
|
|
free(out);
|
|
|
|
}
|
2007-08-04 04:44:23 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if (ldi->ldi_fd != -1) {
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
write(ldi->ldi_fd, out, (int)strlen(out));
|
2007-08-04 04:44:23 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
OPAL_THREAD_UNLOCK(&mutex);
|
|
|
|
free(str);
|
2004-06-29 04:02:25 +04:00
|
|
|
}
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
|
|
|
|
return rc;
|
2004-01-14 09:42:24 +03:00
|
|
|
}
|
2008-02-28 04:57:57 +03:00
|
|
|
|
|
|
|
int opal_output_get_verbosity(int output_id)
|
|
|
|
{
|
|
|
|
if (output_id >= 0 && output_id < OPAL_OUTPUT_MAX_STREAMS && info[output_id].ldi_used) {
|
|
|
|
return info[output_id].ldi_verbose_level;
|
|
|
|
} else {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|