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

Reply via email to