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 then you can provide a meaningful error >>> message that way -- and duplicate messages are not displayed (which many >>> people have told me that they love that feature). BTL_ERROR just guarantees >>> that the user will have to email us to figure out what's going on because >>> the messages aren't meaningful to anyone other than an OMPI developer. >> >> I'm not sure I understand this concern either, especially the latter one >> about orte dependency. There already are 5 calls to orte_show_help in this >> btl, along with several references to orte_process_info and other orte >> elements. What harm is done by adding more calls to orte_show_help? >> >> I better understand the BTL_ERROR issue, but it raises the question as to >> whether BTL_ERROR should be defined as an orte_show_help call. That might >> help reduce the flood of duplicate messages when an error occurs. > > The project where we planned to use the BTL in another context is not dead > yet. We didn't had much help on progressing on that front, but we didn't give > up [yet]. > > 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? > > Thanks, > george. > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
