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
> [email protected]
>
--
Jeff Squyres
[email protected]
