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