Hi Jeff, On Nov 11, 2013, at 2:53 PM, "Jeff Squyres (jsquyres)" <[email protected]> wrote:

On Nov 11, 2013, at 5:34 PM, Kathryn Mohror <[email protected]> wrote:

...

...

The answer we're currently using is what we discussed on the tools call: <prefix> is a state variable with enumeration, and all <prefix><name> pvars are expected to use the mapping of that state variable. For exmple, btl_usnic_num_sends will follow the pattern established by the btl_usnic pvar state variable.

I guess the problem with this (and maybe I'm missing something) is that it will be hard for a tool to know if a particular state variable with an enumeration describes other variables that have the prefix in their names. In other words, how do I know that this state variable is special and not just that some pvars happen to have the same prefix, but there's no relationship between them?

I think what we're trying to say is this:

- for a given pvar category X - if there's a state pvar Y (which therefore has an associated enumeration) - then any pvar in category X that has a name that begins with Y is related to state pvar Y

This has the restriction that you shouldn't give a state pvar a name that is a prefix of some other pvar in the same category (i.e., so that you don't get incorrect relationship implications).

Since this convention is limited to a single category, it may not be too onerous.

Just to clarify: are you proposing that we add this officially to the standard (that particular naming scheme) or is this supposed to be an informal agreement? I personally would like to see the former, since it will be important to have something tools can rely on. Assuming you meant that (that's how I understood it), here is one concern: this scheme is not very flexible - once a name is set and the enumeration variable is provided, this cannot be changed anymore. Isn't this even too restrictive for your case (where NICs can come and go in, e.g., a hot-pluggable system)? In general, the situation can appear in any scenario in which we have a variable that can (doesn't have to at the moment) return a value of more than 1 for the count. Depending on the variable, it can vary greatly in what that means and this can be very dynamic. I think a more dynamic lookup mechanism (e.g., query an enumeration once you have a count and a handle) would be better. Martin

-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

________________________________________________________________________ Martin Schulz, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA