I'm not sure about that -- OPAL_SOS will take some time to propagate
throughout the code base, even after the infrastructure is added to
the trunk.
My point was that it might not be worth it to revamp BTL_ERROR if
OPAL_SOS is coming. But I'd still like to get the new TCP BTL
messages in.
Then let's just be patient until OPAL_SOS make it in the trunk, and save us the
burden of a large effort made twice.
george.
On Mar 5, 2010, at 22:35 , Ralph Castain wrote:
>
> On Mar 5, 2010, at 7:22 PM, Jeff Squyres wrote:
>
>> On Mar 5, 2010, at 6:10 PM, Ralph Castain wrote:
>>
I a
On Mar 5, 2010, at 7:22 PM, Jeff Squyres wrote:
> On Mar 5, 2010, at 6:10 PM, Ralph Castain wrote:
>
>>> I agree with Jeff's comments about the BTL_ERROR. How about a middle ground
>>> here? We let the BTLs use BTL_ERROR, eventually with some modifications,
>>> and we redirect the BTL_ERROR to
On Mar 5, 2010, at 6:10 PM, Ralph Castain wrote:
> > I agree with Jeff's comments about the BTL_ERROR. How about a middle ground
> > here? We let the BTLs use BTL_ERROR, eventually with some modifications,
> > and we redirect the BTL_ERROR to a more advanced macro including support
> > for orte
On Mar 5, 2010, at 3:52 PM, George Bosilca wrote:
>
> On Mar 5, 2010, at 14:59 , Ralph Castain wrote:
>
>>> I have never found BTL_ERROR to be terribly helpful. All it is is
>>> essentially an fprintf -- it doesn't propagate errors upward or anything.
>>> I tend to prefer show_help because
On Mar 5, 2010, at 14:59 , Ralph Castain wrote:
>> I have never found BTL_ERROR to be terribly helpful. All it is is
>> essentially an fprintf -- it doesn't propagate errors upward or anything. I
>> tend to prefer show_help because then you can provide a meaningful error
>> message that way
On Mar 5, 2010, at 12:55 PM, Jeff Squyres wrote:
> On Mar 5, 2010, at 2:34 PM, George Bosilca wrote:
>
>> Being user friendly is good, being way too user friendly is less (but I
>> guess this is the price we have to pay for a production-quality code isn't
>> it).
>
> Agreed. None of these me
On Mar 5, 2010, at 2:34 PM, George Bosilca wrote:
> Being user friendly is good, being way too user friendly is less (but I guess
> this is the price we have to pay for a production-quality code isn't it).
Agreed. None of these messages appear except in error cases or if you crank up
the verbo
Being user friendly is good, being way too user friendly is less (but I guess
this is the price we have to pay for a production-quality code isn't it).
I have few comments:
- In several places you replaced the BTL_ERROR (which was the way BTLs are
supposed to complaints) by a call directly to o
>From https://svn.open-mpi.org/trac/ompi/ticket/2045, I have added a lot more
>diagnostic error and verbose messages to the TCP BTL that detail what
>endpoints it creates, what IP addresses and ports its trying to connect to,
>etc. As part of this, I also added a magic ID string into the TCP BT
10 matches
Mail list logo
