On Apr 27, 2014, at 2:26 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote:
> MCA infra is very powerful and this use-case can be satisfied by introducing > MCA naming convention and checking it programmatically. Yes, it *can* be - I'm saying that we may not *want* to do it that way. :-) > > Changing/updating architecture to fulfill this specific use-case seems a > overkill. The arch is powerfull to resolve it w/o adding specific class > (IMHO). Nobody would be changing the architecture of the system. All I'm suggesting is adding a new variable type. Something like "MCA_BASE_VAR_TYPE_VERSION _STRING" instead of "MCA_BASE_VAR_TYPE_STRING". This eliminates the need to force a standard param string format, and may provide a cleaner mechanism. > > We had "--bynode" cmd line arg in mpirun before which was a wrapper around > specific MCA rmaps param for convenience. > The well-known MCA can be something similar, i guess. > > > > > > On Fri, Apr 25, 2014 at 5:29 PM, Ralph Castain <r...@open-mpi.org> wrote: > So long as this isn't a requirement, I don't see an issue with standardizing > the syntax. I suspect Jeff's concern is with hard-coding ompi_info (and all > its flavors) with an option that looks for a specific MCA param from every > component. Seems somewhat icky from a software design standpoint, and > inflexible. > > Perhaps creating a special MCA param "class" might make that more palatable? > So we aren't looking for a particular string inside an MCA param name when > someone gives that ompi_info option, but instead printing all params of a > specific type? > > > On Apr 25, 2014, at 4:18 AM, Stephen Poole <swpo...@gmail.com> wrote: > >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Although the one Mike suggests would be much easier for "end users", I >> think that in this >> case, if the end user is more of a Linux newbie, they would have scripts >> written for them, >> that the admins use or will be handed to them. Either way would be a >> great addition for >> system/build/runtime verification of the installed libraries. >> >> Best >> Steve... >> >> >> On 4/25/14, 7:13 AM, Jeff Squyres (jsquyres) wrote: >>> On Apr 25, 2014, at 7:01 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: >>> >>>>>>> ompi_info --all --parsable | egrep ':(compile|run)time_version' >>>> >>>> yep, this is much better, but I don`t think we should count on >> end-user to be unix regex guru. >>> >>> I thought you said this was for support scripts? >>> >>> Users can easily do this: >>> >>> ompi_info --all --parsable | grep time_version >>> >>> Or even >>> >>> ompi_info --all --parsable | grep _version >>> >>> Or even >>> >>> ompi_info --all --parsable | grep version >>> >>> >>>> Ideally, following would be much user-friendlier: >>>> >>>> ompi_info --all --parsable --print-sys-libs-versions >>>> >>>> >>>> >>>> >>>> On Fri, Apr 25, 2014 at 1:32 PM, Jeff Squyres (jsquyres) >> <jsquy...@cisco.com> wrote: >>>> On Apr 24, 2014, at 1:38 AM, Mike Dubman <mi...@dev.mellanox.co.il> >> wrote: >>>> >>>>> ** prefix each well-known MCA param with "print_": >>>> >>>> I like the overall idea of this RFC, but I'm not wild about this >> specific word "print" -- it seems weird. All the MCA parameters are >> *printed* -- the word "print" doesn't really distinguish anything here. >>>> >>>> (I know I'm just harping on a word, but I think it's an important >> word here... :-) ) >>>> >>>> Got a better suggestion, perchance? (I don't, offhand...) >>>> >>>>> ** Define two well-known mca parameters indicating external library >> runtime and compiletime versions, i.e.: >>>>> >>>>> print_compiletime_version >>>>> print_runtime_version >>>>> >>>>> The following command will show all exposed well-known mca params >> from all components: >>>>> ompi_info --parsable -l 9 |grep ":print_" >>>> >>>> How about changing this a bit (hoping my regexp syntax is correct at >> 6:30am before coffee...): >>>> >>>> ompi_info --all --parsable | egrep ':(compile|run)time_version' >>>> >>>> Then the "print_" prefix isn't needed. >>>> >>>> -- >>>> Jeff Squyres >>>> jsquy...@cisco.com >>>> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>> >>>> _______________________________________________ >>>> devel mailing list >>>> de...@open-mpi.org >>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/04/14610.php >>>> >>>> _______________________________________________ >>>> devel mailing list >>>> de...@open-mpi.org >>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/04/14611.php >>> >>> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJTWkSZAAoJECiO+w6Set8uDWgP/2Lnx2j1foBu85sRtHwIqU72 >> AdQGPvCqbiXZ3Sn32ODJgCE6lGm38W075HqETN3CFfrawvLLpAjsnLs2mdA1GcZq >> buoPVuFAHQQZ4FM7y+TGUt0NyMAsMDWfBR8t9JdyMZdP7fHYhGitkuGshItivWmQ >> 0j3KYzKFRe9qVGNvAc+f6eG7DnC+vUFNMZZ6APg62mYB7v//4NGhhrvHpYgD5jG2 >> S3kA1QfvM7xPy6rOL4gvyA6LRnFsNnQmKKLEJFXhPazwy5/5Aop8iwc2TxqVBsZE >> Jw4B6ZrTKrQCzfuN4vN6jgeYHwhlZHKZqtVDMoIWHKwhJMvXlH8aTmeDqqj6sAfl >> wknbew6BETuuIkszyRr0BjZrf4zjJ18vqDoRwFNa8p6Wc3cbhK96kl6fXquxTd4z >> GIuRAIVqemEUGNKnGyuItYuVimkkvts5Ve5c/BxpMBT3oQX1LzOxb6+mcwzdR0dD >> HK82VQlycFegLQ9+ERLgYEkcfmyZlvB+x/pwtx9RRMOd177w5fCo8hTTnkmWJNq2 >> jfq5cDiAW7knBJ1ZOGvMjp8RDpBMyMHjr6WCxQC3y+szR0TcMWrFUddcM2/2OBxF >> YfFCP5jaeCQOOmDh1kcntcFoLw43io2xHFr/UwmfXeDhh/IFQrnEmshjvl/ZFF8n >> RZogS6K9ty1C9x5GCBm4 >> =O0Fa >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/04/14613.php > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/04/14617.php > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/04/14619.php
