On May 23, 2008, at 9:56 AM, Josh Hursey wrote:
Unfortunately, as Jeff pointed out, the behavior of frameworks and
components in determining component selection is not consistent in the
codebase. The mca_base_select() commit made things much better, but
there are still frameworks that do not (o
Unfortunately, as Jeff pointed out, the behavior of frameworks and
components in determining component selection is not consistent in the
codebase. The mca_base_select() commit made things much better, but
there are still frameworks that do not (or cannot) use it, and there
are some behavio
I think that technically, the component can do whatever it wants
(e.g., look at its priority, see 0, and decide to return NULL).
However, to be consistent, we should decide on a specific behavior and
make it uniform to all components.
I'd opt for the ^foo notation to disable a component.
This mostly makes sense. But let me probe a little more. Can a
component return NULL if it looks at its priority and the priority is
less than or equal to 0? For example, currently the hierarch component
returns NULL when its priority is equal or less than 0. This means that
as a user whe
Yeah (Sorry I didn't reply earlier).
Each component is asked for at least two items of information:
priority (int), and module (struct *).
The priority can range from [INT_MIN | INT_MAX] with the highest
priority selected, even if that priority is negative.
If the component does not want
We may not have this uniform throughout the code base -- this is one
of the things we wanted to talk about in the Bay area meeting. I
believe that the allowable range for priorities should be [0, 100],
and that if you don't want to be selected, you should return NULL (or
use some other mec
