2005-05-01 04:53:00 +04:00
|
|
|
/*
|
2007-03-17 02:11:45 +03:00
|
|
|
* Copyright (c) 2004-2007 The Trustees of Indiana University and Indiana
|
2005-11-05 22:57:48 +03:00
|
|
|
* University Research and Technology
|
|
|
|
* Corporation. All rights reserved.
|
2006-08-23 07:32:36 +04:00
|
|
|
* Copyright (c) 2004-2006 The University of Tennessee and The University
|
2005-11-05 22:57:48 +03:00
|
|
|
* of Tennessee Research Foundation. All rights
|
|
|
|
* reserved.
|
2006-02-07 06:32:36 +03:00
|
|
|
* Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
2005-05-01 04:53:00 +04:00
|
|
|
* University of Stuttgart. All rights reserved.
|
|
|
|
* Copyright (c) 2004-2005 The Regents of the University of California.
|
|
|
|
* All rights reserved.
|
|
|
|
* $COPYRIGHT$
|
2006-02-07 06:32:36 +03:00
|
|
|
*
|
2005-05-01 04:53:00 +04:00
|
|
|
* Additional copyrights may follow
|
2006-02-07 06:32:36 +03:00
|
|
|
*
|
2005-05-01 04:53:00 +04:00
|
|
|
* $HEADER$
|
|
|
|
*/
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
#include "orte_config.h"
|
|
|
|
|
2005-05-01 04:58:06 +04:00
|
|
|
#include <sys/types.h>
|
2005-05-01 04:53:00 +04:00
|
|
|
#if HAVE_NETINET_IN_H
|
|
|
|
#include <netinet/in.h>
|
|
|
|
#endif
|
|
|
|
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
#include "opal/types.h"
|
2005-07-04 03:31:27 +04:00
|
|
|
#include "opal/util/output.h"
|
2005-05-01 04:53:00 +04:00
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
#include "orte/mca/errmgr/errmgr.h"
|
|
|
|
|
|
|
|
#include "orte/dss/dss_internal.h"
|
|
|
|
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
int orte_dss_pack(orte_buffer_t *buffer, void *src, orte_std_cntr_t num_vals,
|
2005-05-01 04:53:00 +04:00
|
|
|
orte_data_type_t type)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
/* check for error */
|
Bring over the update to terminate orteds that are generated by a dynamic spawn such as comm_spawn. This introduces the concept of a job "family" - i.e., jobs that have a parent/child relationship. Comm_spawn'ed jobs have a parent (the one that spawned them). We track that relationship throughout the lineage - i.e., if a comm_spawned job in turn calls comm_spawn, then it has a parent (the one that spawned it) and a "root" job (the original job that started things).
Accordingly, there are new APIs to the name service to support the ability to get a job's parent, root, immediate children, and all its descendants. In addition, the terminate_job, terminate_orted, and signal_job APIs for the PLS have been modified to accept attributes that define the extent of their actions. For example, doing a "terminate_job" with an attribute of ORTE_NS_INCLUDE_DESCENDANTS will terminate the given jobid AND all jobs that descended from it.
I have tested this capability on a MacBook under rsh, Odin under SLURM, and LANL's Flash (bproc). It worked successfully on non-MPI jobs (both simple and including a spawn), and MPI jobs (again, both simple and with a spawn).
This commit was SVN r12597.
2006-11-14 22:34:59 +03:00
|
|
|
if (NULL == buffer) {
|
2005-05-01 04:53:00 +04:00
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_BAD_PARAM);
|
|
|
|
return ORTE_ERR_BAD_PARAM;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Pack the number of values */
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
if (ORTE_DSS_BUFFER_FULLY_DESC == buffer->type) {
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_dss_store_data_type(buffer, ORTE_STD_CNTR))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
return rc;
|
|
|
|
}
|
2005-05-01 04:54:12 +04:00
|
|
|
}
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_dss_pack_std_cntr(buffer, &num_vals, 1, ORTE_STD_CNTR))) {
|
2005-05-01 04:53:00 +04:00
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Pack the value(s) */
|
2006-02-07 06:32:36 +03:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_dss_pack_buffer(buffer, src, num_vals, type))) {
|
2005-05-01 04:53:00 +04:00
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
}
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
int orte_dss_pack_buffer(orte_buffer_t *buffer, void *src, orte_std_cntr_t num_vals,
|
2005-05-01 04:53:00 +04:00
|
|
|
orte_data_type_t type)
|
|
|
|
{
|
|
|
|
int rc;
|
2006-02-07 06:32:36 +03:00
|
|
|
orte_dss_type_info_t *info;
|
|
|
|
|
2007-01-31 07:24:56 +03:00
|
|
|
OPAL_OUTPUT( ( orte_dss_verbose, "orte_dss_pack_buffer( %p, %p, %lu, %d )\n",
|
|
|
|
(void*)buffer, src, (long unsigned int)num_vals, (int)type ) );
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
/* Pack the declared data type */
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
if (ORTE_DSS_BUFFER_FULLY_DESC == buffer->type) {
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_dss_store_data_type(buffer, type))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
return rc;
|
|
|
|
}
|
2005-05-01 04:53:00 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Lookup the pack function for this type and call it */
|
|
|
|
|
2006-08-23 07:32:36 +04:00
|
|
|
if (NULL == (info = (orte_dss_type_info_t*)orte_pointer_array_get_item(orte_dss_types, type))) {
|
2005-05-01 04:58:06 +04:00
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_PACK_FAILURE);
|
|
|
|
return ORTE_ERR_PACK_FAILURE;
|
2005-05-01 04:54:12 +04:00
|
|
|
}
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2005-05-01 04:58:06 +04:00
|
|
|
if (ORTE_SUCCESS != (rc = info->odti_pack_fn(buffer, src, num_vals, type))) {
|
2005-05-01 04:53:00 +04:00
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
}
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* PACK FUNCTIONS FOR GENERIC SYSTEM TYPES */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* BOOL
|
|
|
|
*/
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_bool(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type)
|
2005-05-01 04:53:00 +04:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2006-12-07 02:19:06 +03:00
|
|
|
/* System types need to always be described so we can properly
|
|
|
|
unpack them. If we aren't fully described, then add the
|
|
|
|
description for this type... */
|
|
|
|
if (ORTE_DSS_BUFFER_FULLY_DESC != buffer->type) {
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_dss_store_data_type(buffer, DSS_TYPE_BOOL))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
/* Turn around and pack the real type */
|
|
|
|
if (ORTE_SUCCESS != (
|
2006-02-07 06:32:36 +03:00
|
|
|
ret = orte_dss_pack_buffer(buffer, src, num_vals, DSS_TYPE_BOOL))) {
|
2005-05-01 04:53:00 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* INT
|
|
|
|
*/
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_int(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type)
|
2005-05-01 04:53:00 +04:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2006-12-07 02:19:06 +03:00
|
|
|
/* System types need to always be described so we can properly
|
|
|
|
unpack them. If we aren't fully described, then add the
|
|
|
|
description for this type... */
|
|
|
|
if (ORTE_DSS_BUFFER_FULLY_DESC != buffer->type) {
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_dss_store_data_type(buffer, DSS_TYPE_INT))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
/* Turn around and pack the real type */
|
|
|
|
if (ORTE_SUCCESS != (
|
2006-02-07 06:32:36 +03:00
|
|
|
ret = orte_dss_pack_buffer(buffer, src, num_vals, DSS_TYPE_INT))) {
|
2005-05-01 04:53:00 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SIZE_T
|
|
|
|
*/
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_sizet(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type)
|
2005-05-01 04:53:00 +04:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2006-12-07 02:19:06 +03:00
|
|
|
/* System types need to always be described so we can properly
|
|
|
|
unpack them. If we aren't fully described, then add the
|
|
|
|
description for this type... */
|
|
|
|
if (ORTE_DSS_BUFFER_FULLY_DESC != buffer->type) {
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_dss_store_data_type(buffer, DSS_TYPE_SIZE_T))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
/* Turn around and pack the real type */
|
|
|
|
if (ORTE_SUCCESS != (
|
2006-02-07 06:32:36 +03:00
|
|
|
ret = orte_dss_pack_buffer(buffer, src, num_vals, DSS_TYPE_SIZE_T))) {
|
2005-05-01 04:53:00 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
}
|
|
|
|
|
2005-05-06 21:00:06 +04:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PID_T
|
|
|
|
*/
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_pid(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type)
|
2005-05-06 21:00:06 +04:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2006-12-07 02:19:06 +03:00
|
|
|
/* System types need to always be described so we can properly
|
|
|
|
unpack them. If we aren't fully described, then add the
|
|
|
|
description for this type... */
|
|
|
|
if (ORTE_DSS_BUFFER_FULLY_DESC != buffer->type) {
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_dss_store_data_type(buffer, DSS_TYPE_PID_T))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-05-06 21:00:06 +04:00
|
|
|
/* Turn around and pack the real type */
|
|
|
|
if (ORTE_SUCCESS != (
|
2006-02-07 06:32:36 +03:00
|
|
|
ret = orte_dss_pack_buffer(buffer, src, num_vals, DSS_TYPE_PID_T))) {
|
2005-05-06 21:00:06 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
}
|
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* PACK FUNCTIONS FOR NON-GENERIC SYSTEM TYPES */
|
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
/*
|
|
|
|
* NULL
|
|
|
|
*/
|
|
|
|
int orte_dss_pack_null(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type)
|
2006-02-07 06:32:36 +03:00
|
|
|
{
|
|
|
|
char null=0x00;
|
|
|
|
char *dst;
|
|
|
|
|
|
|
|
OPAL_OUTPUT( ( orte_dss_verbose, "orte_dss_pack_null * %d\n", num_vals ) );
|
|
|
|
/* check to see if buffer needs extending */
|
|
|
|
if (NULL == (dst = orte_dss_buffer_extend(buffer, num_vals))) {
|
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_OUT_OF_RESOURCE);
|
|
|
|
return ORTE_ERR_OUT_OF_RESOURCE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* store the nulls */
|
|
|
|
memset(dst, (int)null, num_vals);
|
|
|
|
|
|
|
|
/* update buffer pointers */
|
|
|
|
buffer->pack_ptr += num_vals;
|
|
|
|
buffer->bytes_used += num_vals;
|
|
|
|
|
|
|
|
return ORTE_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
/*
|
|
|
|
* BYTE, CHAR, INT8
|
|
|
|
*/
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_byte(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type)
|
2005-05-01 04:53:00 +04:00
|
|
|
{
|
|
|
|
char *dst;
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
OPAL_OUTPUT( ( orte_dss_verbose, "orte_dss_pack_byte * %d\n", num_vals ) );
|
2005-05-01 04:53:00 +04:00
|
|
|
/* check to see if buffer needs extending */
|
2006-02-07 06:32:36 +03:00
|
|
|
if (NULL == (dst = orte_dss_buffer_extend(buffer, num_vals))) {
|
2005-05-01 04:53:00 +04:00
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_OUT_OF_RESOURCE);
|
|
|
|
return ORTE_ERR_OUT_OF_RESOURCE;
|
|
|
|
}
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
/* store the data */
|
|
|
|
memcpy(dst, src, num_vals);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
/* update buffer pointers */
|
2005-05-01 04:54:12 +04:00
|
|
|
buffer->pack_ptr += num_vals;
|
|
|
|
buffer->bytes_used += num_vals;
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
return ORTE_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* INT16
|
|
|
|
*/
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_int16(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type)
|
2005-05-01 04:53:00 +04:00
|
|
|
{
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t i;
|
2005-05-05 22:45:16 +04:00
|
|
|
uint16_t tmp, *srctmp = (uint16_t*) src;
|
2005-05-01 04:53:00 +04:00
|
|
|
char *dst;
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
OPAL_OUTPUT( ( orte_dss_verbose, "orte_dss_pack_int16 * %d\n", num_vals ) );
|
2005-05-01 04:53:00 +04:00
|
|
|
/* check to see if buffer needs extending */
|
2006-02-07 06:32:36 +03:00
|
|
|
if (NULL == (dst = orte_dss_buffer_extend(buffer, num_vals*sizeof(tmp)))) {
|
2005-05-01 04:53:00 +04:00
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_OUT_OF_RESOURCE);
|
|
|
|
return ORTE_ERR_OUT_OF_RESOURCE;
|
|
|
|
}
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
for (i = 0; i < num_vals; ++i) {
|
|
|
|
tmp = htons(srctmp[i]);
|
2005-05-05 22:45:16 +04:00
|
|
|
memcpy(dst, &tmp, sizeof(tmp));
|
|
|
|
dst += sizeof(tmp);
|
2005-05-01 04:53:00 +04:00
|
|
|
}
|
|
|
|
buffer->pack_ptr += num_vals * sizeof(tmp);
|
|
|
|
buffer->bytes_used += num_vals * sizeof(tmp);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
return ORTE_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* INT32
|
|
|
|
*/
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_int32(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type)
|
2005-05-01 04:53:00 +04:00
|
|
|
{
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t i;
|
2005-05-05 22:45:16 +04:00
|
|
|
uint32_t tmp, *srctmp = (uint32_t*) src;
|
2005-05-01 04:53:00 +04:00
|
|
|
char *dst;
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
OPAL_OUTPUT( ( orte_dss_verbose, "orte_dss_pack_int32 * %d\n", num_vals ) );
|
2005-05-01 04:53:00 +04:00
|
|
|
/* check to see if buffer needs extending */
|
2006-02-07 06:32:36 +03:00
|
|
|
if (NULL == (dst = orte_dss_buffer_extend(buffer, num_vals*sizeof(tmp)))) {
|
2005-05-01 04:53:00 +04:00
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_OUT_OF_RESOURCE);
|
|
|
|
return ORTE_ERR_OUT_OF_RESOURCE;
|
|
|
|
}
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
for (i = 0; i < num_vals; ++i) {
|
|
|
|
tmp = htonl(srctmp[i]);
|
2005-05-05 22:45:16 +04:00
|
|
|
memcpy(dst, &tmp, sizeof(tmp));
|
|
|
|
dst += sizeof(tmp);
|
2005-05-01 04:53:00 +04:00
|
|
|
}
|
|
|
|
buffer->pack_ptr += num_vals * sizeof(tmp);
|
|
|
|
buffer->bytes_used += num_vals * sizeof(tmp);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
return ORTE_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* INT64
|
|
|
|
*/
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_int64(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type)
|
2005-05-01 04:53:00 +04:00
|
|
|
{
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t i;
|
2006-03-29 22:58:02 +04:00
|
|
|
uint64_t tmp, *srctmp = (uint64_t*) src;
|
2005-05-01 04:53:00 +04:00
|
|
|
char *dst;
|
2006-03-29 22:58:02 +04:00
|
|
|
size_t bytes_packed = num_vals * sizeof(tmp);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
OPAL_OUTPUT( ( orte_dss_verbose, "orte_dss_pack_int64 * %d\n", num_vals ) );
|
2005-05-01 04:53:00 +04:00
|
|
|
/* check to see if buffer needs extending */
|
2006-02-07 06:32:36 +03:00
|
|
|
if (NULL == (dst = orte_dss_buffer_extend(buffer, bytes_packed))) {
|
2005-05-01 04:53:00 +04:00
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_OUT_OF_RESOURCE);
|
|
|
|
return ORTE_ERR_OUT_OF_RESOURCE;
|
|
|
|
}
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2006-03-29 22:58:02 +04:00
|
|
|
for (i = 0; i < num_vals; ++i) {
|
|
|
|
tmp = hton64(srctmp[i]);
|
2005-05-05 22:45:16 +04:00
|
|
|
memcpy(dst, &tmp, sizeof(tmp));
|
|
|
|
dst += sizeof(tmp);
|
2005-05-01 04:53:00 +04:00
|
|
|
}
|
2005-05-02 22:30:07 +04:00
|
|
|
buffer->pack_ptr += bytes_packed;
|
|
|
|
buffer->bytes_used += bytes_packed;
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2005-05-01 04:53:00 +04:00
|
|
|
return ORTE_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* STRING
|
|
|
|
*/
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_string(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type)
|
2005-05-01 04:53:00 +04:00
|
|
|
{
|
|
|
|
int ret = ORTE_SUCCESS;
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t i, len;
|
2005-05-01 04:53:00 +04:00
|
|
|
char **ssrc = (char**) src;
|
|
|
|
|
|
|
|
for (i = 0; i < num_vals; ++i) {
|
2005-05-13 01:44:23 +04:00
|
|
|
if (NULL == ssrc[i]) { /* got zero-length string/NULL pointer - store NULL */
|
|
|
|
len = 0;
|
2006-08-22 18:58:31 +04:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_dss_pack_std_cntr(buffer, &len, 1, ORTE_STD_CNTR))) {
|
2005-05-13 01:44:23 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
} else {
|
2006-10-20 06:25:50 +04:00
|
|
|
len = (orte_std_cntr_t)strlen(ssrc[i]) + 1;
|
2006-08-22 18:58:31 +04:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_dss_pack_std_cntr(buffer, &len, 1, ORTE_STD_CNTR))) {
|
2005-05-13 01:44:23 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
2006-02-07 06:32:36 +03:00
|
|
|
if (ORTE_SUCCESS != (ret =
|
|
|
|
orte_dss_pack_byte(buffer, ssrc[i], len, ORTE_BYTE))) {
|
2005-05-13 01:44:23 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
2005-05-01 04:53:00 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ORTE_SUCCESS;
|
|
|
|
}
|
2005-05-01 04:54:12 +04:00
|
|
|
|
|
|
|
/* PACK FUNCTIONS FOR GENERIC ORTE TYPES */
|
|
|
|
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
/*
|
|
|
|
* ORTE_STD_CNTR
|
|
|
|
*/
|
|
|
|
int orte_dss_pack_std_cntr(orte_buffer_t *buffer, void *src, orte_std_cntr_t num_vals,
|
|
|
|
orte_data_type_t type)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* Turn around and pack the real type */
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_dss_pack_buffer(buffer, src, num_vals, ORTE_STD_CNTR_T))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2005-05-01 04:54:12 +04:00
|
|
|
/*
|
|
|
|
* ORTE_DATA_TYPE
|
|
|
|
*/
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
int orte_dss_pack_data_type(orte_buffer_t *buffer, void *src, orte_std_cntr_t num_vals,
|
2005-05-01 04:54:12 +04:00
|
|
|
orte_data_type_t type)
|
|
|
|
{
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* Turn around and pack the real type */
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_dss_pack_buffer(buffer, src, num_vals, ORTE_DATA_TYPE_T))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
2006-02-07 06:32:36 +03:00
|
|
|
}
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
|
|
|
|
return ret;
|
2006-02-07 06:32:36 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ORTE_DATA_VALUE
|
|
|
|
*/
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
int orte_dss_pack_data_value(orte_buffer_t *buffer, void *src, orte_std_cntr_t num, orte_data_type_t type)
|
2006-02-07 06:32:36 +03:00
|
|
|
{
|
|
|
|
orte_dss_type_info_t *info;
|
|
|
|
orte_data_value_t **sdv;
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t i;
|
2006-02-07 06:32:36 +03:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
sdv = (orte_data_value_t **) src;
|
|
|
|
|
|
|
|
for (i = 0; i < num; ++i) {
|
2006-12-02 01:30:39 +03:00
|
|
|
/* if the src data value is NULL, then we will pack it as ORTE_NULL to indicate
|
|
|
|
* that the unpack should leave a NULL data value
|
|
|
|
*/
|
|
|
|
if (NULL == sdv[i]) {
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_dss_store_data_type(buffer, ORTE_NULL))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
/* pack the data type - we'll need it on the other end */
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_dss_store_data_type(buffer, sdv[i]->type))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2006-12-02 01:30:39 +03:00
|
|
|
/* if the data type is UNDEF, then nothing more to do */
|
|
|
|
if (ORTE_UNDEF == sdv[i]->type) continue;
|
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
/* Lookup the pack function for this type and call it */
|
|
|
|
|
2006-08-23 07:32:36 +04:00
|
|
|
if (NULL == (info = (orte_dss_type_info_t*)orte_pointer_array_get_item(orte_dss_types, sdv[i]->type))) {
|
2006-02-07 06:32:36 +03:00
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_PACK_FAILURE);
|
|
|
|
return ORTE_ERR_PACK_FAILURE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (info->odti_structured) {
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_dss_pack_buffer(buffer, &(sdv[i]->data), 1, sdv[i]->type))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_dss_pack_buffer(buffer, sdv[i]->data, 1, sdv[i]->type))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ORTE_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2007-03-17 02:11:45 +03:00
|
|
|
#if OPAL_ENABLE_FT == 1
|
|
|
|
/*
|
|
|
|
* ORTE_CKPT_CMD
|
|
|
|
*/
|
|
|
|
int orte_dss_pack_ckpt_cmd(orte_buffer_t *buffer, void *src, orte_std_cntr_t num,
|
|
|
|
orte_data_type_t type)
|
|
|
|
{
|
|
|
|
size_t required;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
required = sizeof(size_t);
|
|
|
|
switch (required) {
|
|
|
|
|
|
|
|
case 1:
|
|
|
|
if (ORTE_SUCCESS != (
|
|
|
|
rc = orte_dss_pack_byte(buffer, src, num, ORTE_BYTE))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 2:
|
|
|
|
if (ORTE_SUCCESS != (
|
|
|
|
rc = orte_dss_pack_int16(buffer, src, num, ORTE_INT16))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 4:
|
|
|
|
if (ORTE_SUCCESS != (
|
|
|
|
rc = orte_dss_pack_int32(buffer, src, num, ORTE_INT32))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 8:
|
|
|
|
if (ORTE_SUCCESS != (
|
|
|
|
rc = orte_dss_pack_int64(buffer, src, num, ORTE_INT64))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_BAD_PARAM);
|
|
|
|
return ORTE_ERR_BAD_PARAM;
|
|
|
|
}
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2005-05-01 04:54:12 +04:00
|
|
|
/*
|
|
|
|
* ORTE_BYTE_OBJECT
|
|
|
|
*/
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
int orte_dss_pack_byte_object(orte_buffer_t *buffer, void *src, orte_std_cntr_t num,
|
2005-05-01 04:54:12 +04:00
|
|
|
orte_data_type_t type)
|
|
|
|
{
|
2006-02-07 06:32:36 +03:00
|
|
|
orte_byte_object_t **sbyteptr;
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t i, n;
|
2005-05-01 04:58:06 +04:00
|
|
|
int ret;
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
sbyteptr = (orte_byte_object_t **) src;
|
2005-05-01 04:58:06 +04:00
|
|
|
|
|
|
|
for (i = 0; i < num; ++i) {
|
2006-02-07 06:32:36 +03:00
|
|
|
n = sbyteptr[i]->size;
|
2006-08-22 18:58:31 +04:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_dss_pack_std_cntr(buffer, &n, 1, ORTE_STD_CNTR))) {
|
2006-02-07 06:32:36 +03:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
2005-05-01 04:58:06 +04:00
|
|
|
if (0 < n) {
|
2006-02-07 06:32:36 +03:00
|
|
|
if (ORTE_SUCCESS != (ret =
|
|
|
|
orte_dss_pack_byte(buffer, sbyteptr[i]->bytes, n, ORTE_BYTE))) {
|
2005-05-01 04:58:06 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2005-05-01 04:54:12 +04:00
|
|
|
return ORTE_SUCCESS;
|
|
|
|
}
|