Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] merging plugins?
From: Samuel Thibault (samuel.thibault_at_[hidden])
Date: 2012-09-25 04:48:18

> >> And a syntax such as pci,^servet to select manually.
> > Why a ^?
> This was for Jeff :)
> When you specify which components to use in OMPI, you pass a
> comma-separated list, and ^ is a negation.

Ok, that's indeed what I understood, it was just conflicting with
what was mentioned above: we wanted to see servet already disabled by
default, and only enabled manually.

Brice Goglin, le Tue 25 Sep 2012 10:17:57 +0200, a écrit :
> Le 25/09/2012 09:49, Samuel Thibault a écrit :
> > One thing which can be confusing for the user is that core_linux goes
> > to the core os list while core_libpci goes to the additional list. It
> > would probably be better to use a different class name. I actually don't
> > currently understand what classes are used for.
> The class name was initially used to distinguish between normal (core)
> plugins and xml backends. It may be possible to completely remove it now
> that component struct have a type, I'll check.

Ok. I was also hit by the fact that core_linux_x86 is not valid, only
one '_' is allowed.

> We have the "core_xml" component (generic xml support) and "xml_libxml"
> + "xml_nolibxml" backends behind that. I am fine with removing the
> "core_" prefix, but I wonder if we should keep the "xml_" prefix for the
> latter.

I'd say we should keep it. Just like I wanted to use core_linux_x86 (as
opposed to core_linux)

> I can easily extend the current code to move pci components out of the
> additional list, make a dedicated list and pick one based on
> priority/envvar.

Well, that still looks hardcoded to me. Actually, a simple way would be
to order all plugins in just one list by priorities. When loading a
plugin, one checks whether the exclusion point of the plugin was already
filled or not, and load the plugin accordingly.

> We should hide xml backends/plugins as much as possible in the doc, we
> have old env variables to deal with those, no need to tell people that
> the way it works changed internally.

You are talking about xml only, not other plugins, right? Well, I
believe it still makes sense to expose the xml ones as loadable just
like the linuxx86 plugin is, or even a user-provided plugin.