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 Castain <r...@open-mpi.org> wrote:

> 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) <dgood...@cisco.com>
> 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
>

Reply via email to