Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] RFC: usnic BTL MPI_T pvar scheme
From: Jeff Squyres (jsquyres) (jsquyres_at_[hidden])
Date: 2013-11-05 22:50:35

Hmm. "_enum" has possibilities.

How about using a * in the name, to represent where the match is? E.G., btl_usnic_*_enum?

It's a string, so it's not just limited to letters and underscores.

Sent from my phone. No type good.

On Nov 5, 2013, at 6:26 PM, "Paul Hargrove" <phhargrove_at_[hidden]<mailto:phhargrove_at_[hidden]>> wrote:

On Tue, Nov 5, 2013 at 6:00 PM, Jeff Squyres (jsquyres) <jsquyres_at_[hidden]<mailto:jsquyres_at_[hidden]>> wrote:
On Nov 5, 2013, at 2:54 PM, Paul Hargrove <phhargrove_at_[hidden]<mailto:phhargrove_at_[hidden]>> wrote:

> If this approach is to be adopted by other components (and perhaps other MPIs), then it would be important for the enumeration variable name to be derived in a UNIFORM way:
> <framework>_<component>_SOMETHING
> Without a fixed value for "SOMETHING" somebody will need to read sources (or documentation) to make the connection.

This is a good point; we got a similar piece of feedback from the MPI tools group.

How about naming the state variable "<framework>_<component>"? And then that will apply to all "<framework>_<component>*" pvars.

Hmm... not sure how that jives with "principle of least astonishment".
Other than that "_SOMETHING" == "" seems like a solution that totally avoids the problems associated with words like "device" (which might imply something about h/w architecture) or "instance" (with potential implications regarding s/w architecture).

So, on balance: +0.9 (my other 0.1 goes to "_enum" for "principle of least astonishment".)


Paul H. Hargrove                          PHHargrove_at_[hidden]<mailto:PHHargrove_at_[hidden]>
Future Technologies Group
Computer and Data Sciences Department     Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900
devel mailing list