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
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. :-)
On Mar 7, 2010, at 11:13 AM, George Bosilca wrote:
> 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.
> 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 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_show_help? This will require going
> over all the BTLs, but on the bright side it will give us a 100%
> consistency on retorting errors.
> >>> Sounds reasonable to me - I'm happy to help do it, assuming Jeff
> also concurs. I assume we would then replace all the show_help calls
> as well? Otherwise, I'm not sure what we gain as the direct
> orte_show_help dependency will remain. Or are those calls too
> specialized to be replaced with BTL_ERROR?
> >> Should this kind of thing wait for OPAL_SOS?
> >> (I mention this because the OPAL_SOS RFC will be sent to devel
> Real Soon Now...)
> > Sure - OPAL_SOS will supersede all this anyway.
> >> --
> >> Jeff Squyres
> >> jsquyres_at_[hidden]
> >> For corporate legal information go to:
> >> http://www.cisco.com/web/about/doing_business/legal/cri/
> >> _______________________________________________
> >> devel mailing list
> >> devel_at_[hidden]
> >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > _______________________________________________
> > devel mailing list
> > devel_at_[hidden]
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> devel mailing list