Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol
From: George Bosilca (bosilca_at_[hidden])
Date: 2014-07-30 20:38:58

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



On Wed, Jul 30, 2014 at 5:40 PM, Ralph Castain <rhc_at_[hidden]> 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) <dgoodell_at_[hidden]>
> 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
> "" (e.g., "").
> >
> > 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
> "". 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
> > devel_at_[hidden]
> > Subscription:
> > Link to this post:
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription:
> Link to this post: