Also, the reason for rfc is this: https://svn.open-mpi.org/trac/ompi/ticket/4556#comment:5
On Fri, Apr 25, 2014 at 7:41 AM, Mike Dubman <[email protected]>wrote: > not a requirement of course, but warm recommendation. Like you mentioned: > "component developers who choose to expose such information do so using > the suggested syntax, then that is a different proposal." > > >>>FWIW: we do not (and cannot, for licensing reasons) link against Slurm, > so please don't include it in such lists to avoid giving anyone even a > passing thought that we do so. > > I don`t understand, today we have "--with-slurm --with-pmi" for dynamic > link with slurm and others where we call slurm functions from OMPI code. > how calling slurm.getVersion() is different? > > afaik, dynamic linking (as we do it today) does not violate current > licensing model. > > > > On Fri, Apr 25, 2014 at 5:39 AM, Ralph Castain <[email protected]> wrote: > >> Just for clarification: are you proposing that we *require* every >> component that links against an external library to include these >> parameters? If so, that seems a significant requirement as quite a few of >> our components do so. >> >> On the other hand, if you are proposing that those component developers >> who choose to expose such information do so using the suggested syntax, >> then that is a different proposal. >> >> Just want to understand what you are proposing - a requirement on >> components, or a syntax for those who choose to support this capability? >> >> FWIW: we do not (and cannot, for licensing reasons) link against Slurm, >> so please don't include it in such lists to avoid giving anyone even a >> passing thought that we do so. >> >> >> >> On Apr 23, 2014, at 10:38 PM, Mike Dubman <[email protected]> >> wrote: >> >> >> WHAT: >> * Formalize well-known MCA parameters that can be used by any component >> to represent external dependencies for this component. >> >> * Component can set that well-known MCA r/o parameters to expose to the >> end-users different setup related traits of the OMPI installation. >> >> Example: >> >> ompi_info can print for every component which depends on external library: >> - ext lib runtime version used by component >> - ext lib compiletime version used by component >> >> slurm: v2.6.6 >> mtl/mxm: v2.5 >> btl/verbs: v3.2 >> btl/usnic: v1.1 >> coll/fca: v2.5 >> ... >> >> End-user or site admin or OMPI vendor can aggregate this information by >> some script and generate report if given installation compiles with >> site/vendor rules. >> >> * The "well-known" mca parameters can be easily extracted from ALL >> components by grep-like utilities. >> >> * Current proposal: >> >> ** prefix each well-known MCA param with "print_": >> ** 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_" >> >> >> WHY: >> >> * Better support-ability: site/vendor can provide script which will check >> if OMPI installation complies to release notes or support matrix. >> >> >> WHEN: >> >> - Next teleconf >> - code can be observed here: >> https://svn.open-mpi.org/trac/ompi/ticket/4556 >> >> >> Comments? >> _______________________________________________ >> devel mailing list >> [email protected] >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/04/14590.php >> >> >> >> _______________________________________________ >> devel mailing list >> [email protected] >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/04/14601.php >> > >
