Ok, I changed the name to "btl_usnic" in SVN (and can change it again if a better suggestion comes by...).
On Nov 5, 2013, at 8:24 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > I stand by my previous "vote" > > "btl_usnic" gets 90% of my vote. > "btl_usnic_enum" gets 10%. > "btl_usnic_*_enum" gets nada. > > Rationale: > While Jeff is correct that the string can legally contain '*', I would > imagine that users would like to have the ability to use wildcards (or even > full regular expressions) when interacting with their tools. For that reason > I'd suggest sticking to just letters, digits and underscore. > > -Paul > > > On Tue, Nov 5, 2013 at 7:50 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> > wrote: > 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" <phhargr...@lbl.gov> wrote: > >> On Tue, Nov 5, 2013 at 6:00 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> >> wrote: >> On Nov 5, 2013, at 2:54 PM, Paul Hargrove <phhargr...@lbl.gov> 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 >> >> >> -- >> Paul H. Hargrove phhargr...@lbl.gov >> 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 >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > -- > Paul H. Hargrove phhargr...@lbl.gov > 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 > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
