There are two more interfaces that have changed:
1. orte_rds.query() now takes a job id, whereas in 1.2b1 it didn't
take any arguments. I seem to remember that I call this to kick orted
into action, but I'm not sure of the implications of not calling it.
In any case, I don't have a job id when I call it, so what do I pass
to get the old behavior?
2. orte_pls.terminate_job() now takes a list of attributes in
addition to a job id. What are the attributes for, and what happens
if I pass a NULL here? Do I need to crate an empty attribute list?
Greg
On Jan 27, 2007, at 6:51 AM, Ralph Castain wrote:
On 1/26/07 11:36 PM, "Greg Watson" <gwat...@lanl.gov> wrote:
I have been using this define to implement the orte_stage_gate_init()
functionality in PTP using OpenMPI 1.2b1 for some months now. As of
1.2b3 it appears that this define has been removed. New users
attempting to build PTP against the latest 1.2b3 build are
complaining that they are getting build errors.
Please let me know what has replaced this define in 1.2b3, and how we
can obtain the same functionality that we had in 1.2b1.
You need to use ORTE_PROC_MY_HNP - no API change is involved, it is
just a
#define. You may need to add #include "orte/mca/ns/ns_types.h" to
pick it
up.
You will also find that ORTE_RML_NAME_ANY is likewise gone - you
need to use
ORTE_NAME_WILDCARD instead for the same reasons as described below.
Similarly, ORTE_RML_NAME_SELF has been replaced by ORTE_PROC_MY_NAME.
We discovered during the testing/debugging of 1.2 that people had
unintentionally created multiple definitions for several critical
names in
the system. Hence, we had an ORTE_RML_NAME_SEED, an ORTE_OOB_SEED, and
several others. In the event that definition had to change, we
found the
code "cracking" all over the place - it was literally impossible to
maintain.
So we bit the bullet and cleaned it up. No API changes were
involved, but we
did remove duplicative defines (and their associated storage
locations).
Hopefully, people will take the time to lookup and use these system-
level
defines instead of re-creating the problem!
Also, I would like to know what the policy of changing interfaces is,
and when in the release cycle you freeze API changes. It's going to
be extremely difficult to release a version of PTP built against
OpenMPI if you change interfaces between beta versions.
In my opinion, that is what "beta" is for - it isn't a "lock-down"
release,
but rather a time to find your cracks and fix them. That said, we
don't
change APIs for no reason, but only because we either (a) needed to
do so to
add some requested functionality (e.g., the recent request for
"pernode"
launch capabilities), or (b) found a bug in the system that
required some
change or added functionality to fix (e.g., the recent changes in
the PLS
behavior and API to support ctrl-c interrupt capabilities).
I generally try to send emails out alerting people to these changes
when
they occur (in fact, I'm pretty certain I sent one out on this issue).
However, looking back, I find that I send them to the OMPI "core
developers"
list - not the "developers" one. I note that the OMPI layer
developers tend
to do the same thing. I'll try to rectify that in the future and
suggest my
OMPI compatriots do so too.
Once an actual release is made, we only make an API change if a
major bug is
found and an API change simply must be done to fix it. I don't
recall such
an instance, though I think it may have happened once between minor
release
numbers in the 1.1 family (not sure).
Greg
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
