1
1
openmpi/opal/util/argv.c

583 строки
13 KiB
C
Исходник Обычный вид История

/*
* Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
* University Research and Technology
* Corporation. All rights reserved.
* Copyright (c) 2004-2005 The University of Tennessee and The University
* of Tennessee Research Foundation. All rights
* reserved.
2015-06-24 06:59:57 +03:00
* Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
* University of Stuttgart. All rights reserved.
* Copyright (c) 2004-2005 The Regents of the University of California.
* All rights reserved.
* Copyright (c) 2007 Voltaire. All rights reserved.
* Copyright (c) 2012 Los Alamos National Security, LLC. All rights reserved.
* Copyright (c) 2015 Research Organization for Information Science
* and Technology (RIST). All rights reserved.
*
* $COPYRIGHT$
2015-06-24 06:59:57 +03:00
*
* Additional copyrights may follow
2015-06-24 06:59:57 +03:00
*
* $HEADER$
*/
#include "opal_config.h"
#include <stdlib.h>
#include <string.h>
#include "opal/util/argv.h"
#include "opal/constants.h"
#define ARGSIZE 128
/*
* Append a string to the end of a new or existing argv array.
*/
int opal_argv_append(int *argc, char ***argv, const char *arg)
{
int rc;
2015-06-24 06:59:57 +03:00
/* add the new element */
if (OPAL_SUCCESS != (rc = opal_argv_append_nosize(argv, arg))) {
return rc;
}
2015-06-24 06:59:57 +03:00
*argc = opal_argv_count(*argv);
2015-06-24 06:59:57 +03:00
return OPAL_SUCCESS;
}
int opal_argv_append_nosize(char ***argv, const char *arg)
{
int argc;
2015-06-24 06:59:57 +03:00
/* Create new argv. */
if (NULL == *argv) {
*argv = (char**) malloc(2 * sizeof(char *));
if (NULL == *argv) {
return OPAL_ERR_OUT_OF_RESOURCE;
}
argc = 0;
(*argv)[0] = NULL;
(*argv)[1] = NULL;
}
/* Extend existing argv. */
else {
/* count how many entries currently exist */
argc = opal_argv_count(*argv);
2015-06-24 06:59:57 +03:00
*argv = (char**) realloc(*argv, (argc + 2) * sizeof(char *));
if (NULL == *argv) {
return OPAL_ERR_OUT_OF_RESOURCE;
}
}
/* Set the newest element to point to a copy of the arg string */
(*argv)[argc] = strdup(arg);
if (NULL == (*argv)[argc]) {
return OPAL_ERR_OUT_OF_RESOURCE;
}
argc = argc + 1;
(*argv)[argc] = NULL;
return OPAL_SUCCESS;
}
int opal_argv_prepend_nosize(char ***argv, const char *arg)
{
int argc;
int i;
/* Create new argv. */
if (NULL == *argv) {
*argv = (char**) malloc(2 * sizeof(char *));
if (NULL == *argv) {
return OPAL_ERR_OUT_OF_RESOURCE;
}
(*argv)[0] = strdup(arg);
(*argv)[1] = NULL;
} else {
/* count how many entries currently exist */
argc = opal_argv_count(*argv);
2015-06-24 06:59:57 +03:00
*argv = (char**) realloc(*argv, (argc + 2) * sizeof(char *));
if (NULL == *argv) {
return OPAL_ERR_OUT_OF_RESOURCE;
}
(*argv)[argc+1] = NULL;
/* shift all existing elements down 1 */
for (i=argc; 0 < i; i--) {
(*argv)[i] = (*argv)[i-1];
}
(*argv)[0] = strdup(arg);
}
return OPAL_SUCCESS;
}
int opal_argv_append_unique_nosize(char ***argv, const char *arg, bool overwrite)
{
int i;
2015-06-24 06:59:57 +03:00
/* if the provided array is NULL, then the arg cannot be present,
* so just go ahead and append
*/
if (NULL == *argv) {
return opal_argv_append_nosize(argv, arg);
}
2015-06-24 06:59:57 +03:00
/* see if this arg is already present in the array */
for (i=0; NULL != (*argv)[i]; i++) {
if (0 == strcmp(arg, (*argv)[i])) {
/* already exists - are we authorized to overwrite? */
if (overwrite) {
free((*argv)[i]);
(*argv)[i] = strdup(arg);
}
return OPAL_SUCCESS;
}
}
/* we get here if the arg is not in the array - so add it */
return opal_argv_append_nosize(argv, arg);
}
/*
* Free a NULL-terminated argv array.
*/
void opal_argv_free(char **argv)
{
char **p;
if (NULL == argv)
return;
for (p = argv; NULL != *p; ++p) {
free(*p);
}
free(argv);
}
/*
* Split a string into a NULL-terminated argv array.
*/
static char **opal_argv_split_inter(const char *src_string, int delimiter,
int include_empty)
{
char arg[ARGSIZE];
char **argv = NULL;
const char *p;
char *argtemp;
int argc = 0;
size_t arglen;
while (src_string && *src_string) {
p = src_string;
arglen = 0;
while (('\0' != *p) && (*p != delimiter)) {
++p;
++arglen;
}
/* zero length argument, skip */
if (src_string == p) {
if (include_empty) {
arg[0] = '\0';
if (OPAL_SUCCESS != opal_argv_append(&argc, &argv, arg))
return NULL;
}
}
/* tail argument, add straight from the original string */
else if ('\0' == *p) {
if (OPAL_SUCCESS != opal_argv_append(&argc, &argv, src_string))
return NULL;
src_string = p;
continue;
}
/* long argument, malloc buffer, copy and add */
else if (arglen > (ARGSIZE - 1)) {
argtemp = (char*) malloc(arglen + 1);
if (NULL == argtemp)
return NULL;
strncpy(argtemp, src_string, arglen);
argtemp[arglen] = '\0';
if (OPAL_SUCCESS != opal_argv_append(&argc, &argv, argtemp)) {
free(argtemp);
return NULL;
}
free(argtemp);
}
/* short argument, copy to buffer and add */
else {
strncpy(arg, src_string, arglen);
arg[arglen] = '\0';
if (OPAL_SUCCESS != opal_argv_append(&argc, &argv, arg))
return NULL;
}
src_string = p + 1;
}
/* All done */
return argv;
}
char **opal_argv_split(const char *src_string, int delimiter)
{
return opal_argv_split_inter(src_string, delimiter, 0);
}
char **opal_argv_split_with_empty(const char *src_string, int delimiter)
{
return opal_argv_split_inter(src_string, delimiter, 1);
}
/*
* Return the length of a NULL-terminated argv array.
*/
int opal_argv_count(char **argv)
{
char **p;
int i;
if (NULL == argv)
return 0;
for (i = 0, p = argv; *p; i++, p++)
continue;
return i;
}
/*
* Join all the elements of an argv array into a single
* newly-allocated string.
*/
char *opal_argv_join(char **argv, int delimiter)
{
char **p;
char *pp;
char *str;
size_t str_len = 0;
size_t i;
/* Bozo case */
if (NULL == argv || NULL == argv[0]) {
return strdup("");
}
/* Find the total string length in argv including delimiters. The
last delimiter is replaced by the NULL character. */
for (p = argv; *p; ++p) {
str_len += strlen(*p) + 1;
}
/* Allocate the string. */
if (NULL == (str = (char*) malloc(str_len)))
return NULL;
/* Loop filling in the string. */
str[--str_len] = '\0';
p = argv;
pp = *p;
for (i = 0; i < str_len; ++i) {
if ('\0' == *pp) {
/* End of a string, fill in a delimiter and go to the next
string. */
str[i] = (char) delimiter;
++p;
pp = *p;
} else {
str[i] = *pp++;
}
}
/* All done */
return str;
}
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
/*
* Join all the elements of an argv array from within a
* specified range into a single newly-allocated string.
*/
char *opal_argv_join_range(char **argv, size_t start, size_t end, int delimiter)
{
char **p;
char *pp;
char *str;
size_t str_len = 0;
size_t i;
2015-06-24 06:59:57 +03:00
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
/* Bozo case */
2015-06-24 06:59:57 +03:00
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
if (NULL == argv || NULL == argv[0] || (int)start > opal_argv_count(argv)) {
return strdup("");
}
2015-06-24 06:59:57 +03:00
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
/* Find the total string length in argv including delimiters. The
last delimiter is replaced by the NULL character. */
2015-06-24 06:59:57 +03:00
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
for (p = &argv[start], i=start; *p && i < end; ++p, ++i) {
str_len += strlen(*p) + 1;
}
2015-06-24 06:59:57 +03:00
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
/* Allocate the string. */
2015-06-24 06:59:57 +03:00
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
if (NULL == (str = (char*) malloc(str_len)))
return NULL;
2015-06-24 06:59:57 +03:00
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
/* Loop filling in the string. */
2015-06-24 06:59:57 +03:00
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
str[--str_len] = '\0';
p = &argv[start];
pp = *p;
2015-06-24 06:59:57 +03:00
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
for (i = 0; i < str_len; ++i) {
if ('\0' == *pp) {
2015-06-24 06:59:57 +03:00
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
/* End of a string, fill in a delimiter and go to the next
string. */
2015-06-24 06:59:57 +03:00
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
str[i] = (char) delimiter;
++p;
pp = *p;
} else {
str[i] = *pp++;
}
}
2015-06-24 06:59:57 +03:00
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
/* All done */
2015-06-24 06:59:57 +03:00
Per the July technical meeting: Standardize the handling of the orte launch agent option across PLMs. This has been a consistent complaint I have received - each PLM would register its own MCA param to get input on the launch agent for remote nodes (in fact, one or two didn't, but most did). This would then get handled in various and contradictory ways. Some PLMs would accept only a one-word input. Others accepted multi-word args such as "valgrind orted", but then some would error by putting any prefix specified on the cmd line in front of the incorrect argument. For example, while using the rsh launcher, if you specified "valgrind orted" as your launch agent and had "--prefix foo" on you cmd line, you would attempt to execute "ssh foo/valgrind orted" - which obviously wouldn't work. This was all -very- confusing to users, who had to know which PLM was being used so they could even set the right mca param in the first place! And since we don't warn about non-recognized or non-used mca params, half of the time they would wind up not doing what they thought they were telling us to do. To solve this problem, we did the following: 1. removed all mca params from the individual plms for the launch agent 2. added a new mca param "orte_launch_agent" for this purpose. To further simplify for users, this comes with a new cmd line option "--launch-agent" that can take a multi-word string argument. The value of the param defaults to "orted". 3. added a PLM base function that processes the orte_launch_agent value and adds the contents to a provided argv array. This can subsequently be harvested at-will to handle multi-word values 4. modified the PLMs to use this new function. All the PLMs except for the rsh PLM required very minor change - just called the function and moved on. The rsh PLM required much larger changes as - because of the rsh/ssh cmd line limitations - we had to correctly prepend any provided prefix to the correct argv entry. 5. added a new opal_argv_join_range function that allows the caller to "join" argv entries between two specified indices Please let me know of any problems. I tried to make this as clean as possible, but cannot compile all PLMs to ensure all is correct. This commit was SVN r19097.
2008-07-30 22:26:24 +04:00
return str;
}
/*
* Return the number of bytes consumed by an argv array.
*/
size_t opal_argv_len(char **argv)
{
char **p;
size_t length;
if (NULL == argv)
return (size_t) 0;
length = sizeof(char *);
for (p = argv; *p; ++p) {
length += strlen(*p) + 1 + sizeof(char *);
}
return length;
}
/*
* Copy a NULL-terminated argv array.
*/
char **opal_argv_copy(char **argv)
{
char **dupv = NULL;
int dupc = 0;
if (NULL == argv)
return NULL;
/* create an "empty" list, so that we return something valid if we
were passed a valid list with no contained elements */
dupv = (char**) malloc(sizeof(char*));
dupv[0] = NULL;
while (NULL != *argv) {
if (OPAL_SUCCESS != opal_argv_append(&dupc, &dupv, *argv)) {
opal_argv_free(dupv);
return NULL;
}
++argv;
}
/* All done */
return dupv;
}
int opal_argv_delete(int *argc, char ***argv, int start, int num_to_delete)
{
int i;
int count;
int suffix_count;
char **tmp;
/* Check for the bozo cases */
if (NULL == argv || NULL == *argv || 0 == num_to_delete) {
return OPAL_SUCCESS;
}
count = opal_argv_count(*argv);
if (start > count) {
return OPAL_SUCCESS;
} else if (start < 0 || num_to_delete < 0) {
return OPAL_ERR_BAD_PARAM;
}
/* Ok, we have some tokens to delete. Calculate the new length of
the argv array. */
suffix_count = count - (start + num_to_delete);
if (suffix_count < 0) {
suffix_count = 0;
}
/* Free all items that are being deleted */
for (i = start; i < count && i < start + num_to_delete; ++i) {
free((*argv)[i]);
}
/* Copy the suffix over the deleted items */
for (i = start; i < start + suffix_count; ++i) {
(*argv)[i] = (*argv)[i + num_to_delete];
}
/* Add the trailing NULL */
(*argv)[i] = NULL;
/* adjust the argv array */
tmp = (char**)realloc(*argv, sizeof(char*) * (i + 1));
if (NULL != tmp) *argv = tmp;
/* adjust the argc */
(*argc) -= num_to_delete;
return OPAL_SUCCESS;
}
int opal_argv_insert(char ***target, int start, char **source)
{
int i, source_count, target_count;
int suffix_count;
/* Check for the bozo cases */
2015-06-24 06:59:57 +03:00
if (NULL == target || NULL == *target || start < 0) {
return OPAL_ERR_BAD_PARAM;
} else if (NULL == source) {
return OPAL_SUCCESS;
}
/* Easy case: appending to the end */
target_count = opal_argv_count(*target);
source_count = opal_argv_count(source);
if (start > target_count) {
for (i = 0; i < source_count; ++i) {
opal_argv_append(&target_count, target, source[i]);
}
}
/* Harder: insertting into the middle */
else {
/* Alloc out new space */
2015-06-24 06:59:57 +03:00
*target = (char**) realloc(*target,
sizeof(char *) * (target_count + source_count + 1));
/* Move suffix items down to the end */
suffix_count = target_count - start;
for (i = suffix_count - 1; i >= 0; --i) {
(*target)[start + source_count + i] =
(*target)[start + i];
}
(*target)[start + suffix_count + source_count] = NULL;
/* Strdup in the source argv */
for (i = start; i < start + source_count; ++i) {
(*target)[i] = strdup(source[i - start]);
}
}
/* All done */
return OPAL_SUCCESS;
}
int opal_argv_insert_element(char ***target, int location, char *source)
{
int i, target_count;
int suffix_count;
2015-06-24 06:59:57 +03:00
/* Check for the bozo cases */
2015-06-24 06:59:57 +03:00
if (NULL == target || NULL == *target || location < 0) {
return OPAL_ERR_BAD_PARAM;
} else if (NULL == source) {
return OPAL_SUCCESS;
}
2015-06-24 06:59:57 +03:00
/* Easy case: appending to the end */
target_count = opal_argv_count(*target);
if (location > target_count) {
opal_argv_append(&target_count, target, source);
return OPAL_SUCCESS;
}
2015-06-24 06:59:57 +03:00
/* Alloc out new space */
2015-06-24 06:59:57 +03:00
*target = (char**) realloc(*target,
sizeof(char*) * (target_count + 2));
2015-06-24 06:59:57 +03:00
/* Move suffix items down to the end */
suffix_count = target_count - location;
for (i = suffix_count - 1; i >= 0; --i) {
(*target)[location + 1 + i] =
(*target)[location + i];
}
(*target)[location + suffix_count + 1] = NULL;
2015-06-24 06:59:57 +03:00
/* Strdup in the source */
(*target)[location] = strdup(source);
2015-06-24 06:59:57 +03:00
/* All done */
return OPAL_SUCCESS;
}