Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol
Yeah, I forgot that pure ANSI C doesn't really have namespaces, other than to fully qualify modules and variables. Bummer. Makes writing large, maintainable middleware more difficult. -Original Message- From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Kenneth A. Lloyd Sent: Thursday, July 31, 2014 6:04 AM To: 'Open MPI Developers' Subject: Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol Doesn't namespacing obviate the need for this convoluted identifier scheme? See, for example, UML package import and include behaviors. -Original Message- From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Dave Goodell (dgoodell) Sent: Wednesday, July 30, 2014 3:35 PM To: Open MPI Developers Subject: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol Jeff and I were talking about some namespacing issues that have come up in the recent BTL move from OMPI to OPAL. AFAIK, the current system for namespacing external symbols is to name them "mca_FRAMEWORK_COMPONENT_symbol" (e.g., "mca_btl_tcp_add_procs" in the tcp BTL). Similarly, the DSO for the component is named "mca_FRAMEWORK_COMPONENT.so" (e.g., "mca_btl_tcp.so"). Jeff asserted that the eventual goal is to move to a system where all MCA frameworks/components are also prefixed by the project name. So the above examples become "mca_ompi_btl_tcp_add_procs" and "mca_ompi_btl_tcp.so". Does anyone actually care about pursuing this goal? I ask because if nobody wants to pursue the goal of adding project names to namespaces then I already have an easy solution to most of our namespacing problems. OTOH, if someone does wish to pursue that goal, then I have a namespace-related RFC that I would like to propose (in a subsequent email). -Dave ___ 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/07/15371.php - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4716 / Virus Database: 3986/7949 - Release Date: 07/30/14 ___ 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/07/15392.php - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4716 / Virus Database: 3986/7951 - Release Date: 07/30/14
Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol
Doesn't namespacing obviate the need for this convoluted identifier scheme? See, for example, UML package import and include behaviors. -Original Message- From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Dave Goodell (dgoodell) Sent: Wednesday, July 30, 2014 3:35 PM To: Open MPI Developers Subject: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol Jeff and I were talking about some namespacing issues that have come up in the recent BTL move from OMPI to OPAL. AFAIK, the current system for namespacing external symbols is to name them "mca_FRAMEWORK_COMPONENT_symbol" (e.g., "mca_btl_tcp_add_procs" in the tcp BTL). Similarly, the DSO for the component is named "mca_FRAMEWORK_COMPONENT.so" (e.g., "mca_btl_tcp.so"). Jeff asserted that the eventual goal is to move to a system where all MCA frameworks/components are also prefixed by the project name. So the above examples become "mca_ompi_btl_tcp_add_procs" and "mca_ompi_btl_tcp.so". Does anyone actually care about pursuing this goal? I ask because if nobody wants to pursue the goal of adding project names to namespaces then I already have an easy solution to most of our namespacing problems. OTOH, if someone does wish to pursue that goal, then I have a namespace-related RFC that I would like to propose (in a subsequent email). -Dave ___ 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/07/15371.php - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4716 / Virus Database: 3986/7949 - Release Date: 07/30/14
Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol
I can also picture an environment where different projects can supply component that would technically belong to a framework from another project. Let me take an example. Imagine we decide to keep the RML-based connection setup for SM, thing that is not currently possible in the OPAL layer. In this case the default OPAL build will only propose generic connection capabilities, such as connection method using an atomic file opening operation. However, the OMPI layer could provide a connector components, that will expose the same interface as the OPAL connectors, but will have access to the RML communications via the selected RTE. Today, because the project name is not in the naming scheme such an approach is possible... George. George. On Wed, Jul 30, 2014 at 5:40 PM, Ralph Castainwrote: > We've run into the same problem with frameworks in different projects > having overlapping names, let alone symbols. So if you have an easy > solution, please go for it. What we need is for not only the symbols, but > the mca libs to contain the project names so they don't overlap each other. > > > On Jul 30, 2014, at 2:34 PM, Dave Goodell (dgoodell) > wrote: > > > Jeff and I were talking about some namespacing issues that have come up > in the recent BTL move from OMPI to OPAL. AFAIK, the current system for > namespacing external symbols is to name them > "mca_FRAMEWORK_COMPONENT_symbol" (e.g., "mca_btl_tcp_add_procs" in the tcp > BTL). Similarly, the DSO for the component is named > "mca_FRAMEWORK_COMPONENT.so" (e.g., "mca_btl_tcp.so"). > > > > Jeff asserted that the eventual goal is to move to a system where all > MCA frameworks/components are also prefixed by the project name. So the > above examples become "mca_ompi_btl_tcp_add_procs" and > "mca_ompi_btl_tcp.so". Does anyone actually care about pursuing this goal? > > > > I ask because if nobody wants to pursue the goal of adding project names > to namespaces then I already have an easy solution to most of our > namespacing problems. OTOH, if someone does wish to pursue that goal, then > I have a namespace-related RFC that I would like to propose (in a > subsequent email). > > > > -Dave > > > > ___ > > 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/07/15371.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/07/15372.php >
Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol
We've run into the same problem with frameworks in different projects having overlapping names, let alone symbols. So if you have an easy solution, please go for it. What we need is for not only the symbols, but the mca libs to contain the project names so they don't overlap each other. On Jul 30, 2014, at 2:34 PM, Dave Goodell (dgoodell)wrote: > Jeff and I were talking about some namespacing issues that have come up in > the recent BTL move from OMPI to OPAL. AFAIK, the current system for > namespacing external symbols is to name them "mca_FRAMEWORK_COMPONENT_symbol" > (e.g., "mca_btl_tcp_add_procs" in the tcp BTL). Similarly, the DSO for the > component is named "mca_FRAMEWORK_COMPONENT.so" (e.g., "mca_btl_tcp.so"). > > Jeff asserted that the eventual goal is to move to a system where all MCA > frameworks/components are also prefixed by the project name. So the above > examples become "mca_ompi_btl_tcp_add_procs" and "mca_ompi_btl_tcp.so". Does > anyone actually care about pursuing this goal? > > I ask because if nobody wants to pursue the goal of adding project names to > namespaces then I already have an easy solution to most of our namespacing > problems. OTOH, if someone does wish to pursue that goal, then I have a > namespace-related RFC that I would like to propose (in a subsequent email). > > -Dave > > ___ > 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/07/15371.php
[OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol
Jeff and I were talking about some namespacing issues that have come up in the recent BTL move from OMPI to OPAL. AFAIK, the current system for namespacing external symbols is to name them "mca_FRAMEWORK_COMPONENT_symbol" (e.g., "mca_btl_tcp_add_procs" in the tcp BTL). Similarly, the DSO for the component is named "mca_FRAMEWORK_COMPONENT.so" (e.g., "mca_btl_tcp.so"). Jeff asserted that the eventual goal is to move to a system where all MCA frameworks/components are also prefixed by the project name. So the above examples become "mca_ompi_btl_tcp_add_procs" and "mca_ompi_btl_tcp.so". Does anyone actually care about pursuing this goal? I ask because if nobody wants to pursue the goal of adding project names to namespaces then I already have an easy solution to most of our namespacing problems. OTOH, if someone does wish to pursue that goal, then I have a namespace-related RFC that I would like to propose (in a subsequent email). -Dave