On Aug 17, 2007, at 8:22 AM, Sven Stork wrote:
What's about this. Every component choose its own tag independent
from the
others. Before a component can use the tag it must register with
its full
name and the tag at a small (process intern) database. If 2
components try to
register the same
On Friday 17 August 2007 13:58, Jeff Squyres wrote:
> On Aug 16, 2007, at 1:13 PM, Tim Prins wrote:
>
> >> So you're both right. :-) But Tim's falling back on an older (and
> >> unfortunately bad) precedent. It would be nice to not extend that
> >> bad precedent, IMHO...
> >
> > I really don't
On Aug 16, 2007, at 1:13 PM, Tim Prins wrote:
So you're both right. :-) But Tim's falling back on an older (and
unfortunately bad) precedent. It would be nice to not extend that
bad precedent, IMHO...
I really don't care where the constants are defined, but they do
need to
be unique. I th
Jeff Squyres wrote:
On Aug 16, 2007, at 11:48 AM, Tim Prins wrote:
+#define ORTE_RML_TAG_UDAPL 25
+#define ORTE_RML_TAG_OPENIB 26
+#define ORTE_RML_TAG_MVAPI 27
I think that UDAPL, OPENIB, MVAPI should not appear anywhere in the
ORTE layer ...
On Aug 16, 2007, at 11:48 AM, Tim Prins wrote:
+#define ORTE_RML_TAG_UDAPL 25
+#define ORTE_RML_TAG_OPENIB 26
+#define ORTE_RML_TAG_MVAPI 27
I think that UDAPL, OPENIB, MVAPI should not appear anywhere in the
ORTE layer ...
I tend to agree with
George Bosilca wrote:
Was there a real reason for this commit ? Was the previous code
broken ?
I'm not aware of it ever breaking for anyone. However, it is a potential
problem if the right combination of networks are used, since multiple
btls are listening on the same tag.
It's not that I ha
Was there a real reason for this commit ? Was the previous code
broken ? It's not that I have anything against the fact that they all
have different RML tags, but I do have something against this snippet:
+#define ORTE_RML_TAG_UDAPL 25
+#define ORTE_RML_TAG_OPENIB
