I forgot to include the patch itself -- here's a mercurial commit showing the 
change:

    http://bitbucket.org/jsquyres/ummunot/changeset/d0dd138df4e5/

If no one objects (and I don't think that anyone will), I'll commit later today.



On Jan 7, 2010, at 3:03 PM, Jeff Squyres wrote:

> WHAT: Make the MCA base not print an error message when a component.open() 
> function returns OPAL_ERR_NOT_AVAILABLE.
> 
> WHY: There's currently no silent way for a component to disqualify itself 
> during component.open().
> 
> WHERE: opal/mca/base/mca_base_components.c
> 
> WHEN: "Soon"
> 
> TIMEOUT: Next Tuesday teleconf, 12 Jan 2009 (short timeout because I don't 
> expect this to be controverial)
> 
> -----
> 
> I'm bringing this up because technically this is in the very core of the MCA 
> loading process, so it should go by a few other eyes instead of just 
> committing it.  That being said, it's a pretty simple thing.
> 
> The rationale here is that some components may know right away during their 
> component register or open functions that they want to be disqualified from 
> the entire process.  In the code today, however, if any component register or 
> open function returns != OPAL_SUCCESS, an error message is printed, like this:
> 
>    [hostname:pid] mca: base: components_open: component btl / foo open 
> function failed
> 
> But I think that there *are* cases where a component can know that it wants 
> to disqualify itself right away, and therefore it should be able to return 
> some sort of sentinel value from component.register() or component.open() 
> that indicates "just go ahead and silently disqualify / discard me now".
> 
> I came across this case in the merge of the ummunotify stuff with the 
> ptmalloc2 component.  It's quite possible that, at run time, the component 
> will determine that neither of those mechanisms are available, and therefore 
> it wants to disqualify itself (it'll know this during component.open()).  
> Right now, there's no way to do so without causing an error message.  My 
> proposal fixes this case.
> 
> I don't think that this is a big deal; I just wanted other people to eyeball 
> it and ensure I'm not proposing anything insane.
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> 


-- 
Jeff Squyres
jsquy...@cisco.com


Reply via email to